[haiku-bugs] Re: [Haiku] #8085: SMI storm on USB handover on AMD 970/SB950 AMD AM3+ UEFI motherboard

#8085: SMI storm on USB handover on AMD 970/SB950 AMD AM3+ UEFI motherboard
-----------------------------+-----------------------------------------
   Reporter:  kallisti5      |      Owner:  mmlr
       Type:  bug            |     Status:  in-progress
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:  SB950,UEFI, AHCI, APIC, IRQ
 Blocked By:                 |   Blocking:
Has a Patch:  1              |   Platform:  All
-----------------------------+-----------------------------------------

Comment (by mmlr):

 Replying to [comment:16 kallisti5]:
 > Don't worry, I wouldn't commit anything like this until extensive
 testing and review :)

 Yet the patches do exactly the two things I mentioned as not necessarily
 being a good idea...

 > Pretty much I'm waiting until after requesting control of usb from SMM
 to disable interrupts, or disabling them before a USB resume / reset
 (depending on the situation)

 As I said above, this is not really an option. You can't delay it until
 after requesting control. This is a race condition that depends entirely
 on how the startup is timed. If there is a device and the SMM is in
 control, then that device can (and will) cause interrupts. If you request
 control now you may very well end up with interrupts being delivered
 before you even return to your code. Those aren't handled and will cause
 an interrupt storm. Hence why I suggested to leave the code in the place
 where it is, but exclude disabling of the ownership change interrupt only.

 Avoiding the reset is certainly a nice thing considering the delays the
 reset introduces. But if it doesn't work on some controllers then either
 we need to blacklist/whitelist them or we should IMO remain with the more
 conservative approach of always resetting.

 Just keep in mind that the ReactOS implementation is new. It is in part
 based on other implementations (including ours), but basically one has to
 assume that it isn't broadly tested just yet. So doing the same thing as a
 younger implementation instead of doing what more established ones came to
 do in the end just doesn't seem like a reasonable approach to me. Our
 implementation started out "by the book" originally and the handover code
 was later adjusted based on input taken from Linux and FreeBSD.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/8085#comment:17>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: