8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2?

John Baldwin jhb at freebsd.org
Mon Jul 12 12:51:54 UTC 2010


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


More information about the freebsd-stable mailing list