#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.