On Friday, July 09, 2010 7:53:39 pm Markus Gebert wrote: > > I'm curious if disabling USB legacy support in the BIOS causes it to still > > die > > even with ehci not loaded. If so, then the SMI# for the ehci controller > > must > > somehow prevent the issue, perhaps by triggering frequently enough to slow > > the > > rate of I/O requests down? > > > I disabled usb legacy support in the BIOS and booted a kernel with > usb+ohci+ukbd+ums but without ehci. Unfortunately, I cannot reproduce the MCE.
Ok, that kills that theory then. > Just to get you right: your theory is that when we don't load the ehci > driver, then the ehci-controller isn't taken over during boot and therefore handled through SMM so that SMIs might occur often enough to throttle the system just enough to not let the problem appear? I'm not very familiar with usb legacy support and SMM, but why would ehci be handled through SMM when the only usb devices (the virtual keyboard and mouse) actually sit on ohci? And why would disabling legacy support help getting more SMIs to throttle the system? As I unterstand this, and I might be terribly wrong, legacy support is what would cause SMIs in the first place. 1) Yes. 2) Many of the legacy USB emulations are very dumb and are polled rather than interrupt driven. Thus, if legacy USB support is enabled, then a timer kicks off an SMI# every so often (at least once a second on some machines, perhaps even more frequent) that polls the USB bus for any device attach/detach events. I think it might also poll attached keyboards that way as well. 3) I thought that disabling legacy USB but _not_ loading ehci would case it to break the same way that loading ehci causes it to break as it would turn off the SMI#'s that loading ehci also disables. -- John Baldwin _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
