Date: Sun, 23 Oct 2005 04:41:15 +0000 (GMT) From: wpaul@FreeBSD.ORG (Bill Paul) To: freebsd-current@freebsd.org Subject: The case of the missing USB controllers Message-ID: <20051023044115.7050216A421@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
I have a Sun w2100z dual Opteron workstation which, like many machines these days, uses a USB keyboard and mouse and has no legacy PS2 keyboard port. The machine has several USB controllers and FreeBSD likes them just fine -- _when_ it actually manages to detect and attach the controllers correctly. Unfortunately, it very often doesn't. Now, it's not that the ohci or ehci drivers are causing problems: it's that the PCI bridge code fails to find the devices when enumerating the PCI bus on which the controllers reside. It happens it's an ACPI bus, which I'm sure is part of the problem. Right now, I have three different OSes installed: Solaris 10/amd64, FreeBSD 6.0BETA4/i386 and FreeBSD 6.0BETA4/amd64. I typically see the following behavior: - FreeBSD 6.0BETA4/i386: successfully finds the controllers the majority of the time, but will occasionally miss them. Failure rate is maybe 1 bootup out of 10. Note that this behavior has improved from earlier 6.0-current snapshots, where I had maybe a 50-50 chance of the USB controllers being found on any given boot. - FreeBSD 6.0BETA4/amd64: completely fails to find the controllers the majority of the time, only successfully maybe once in a blue moon. - Solaris 10/amd64: always finds the controllers successfully I have the verbose dmesg output for a successful boot here: http://www.freebsd.org/~wpaul/opteron/dmesg.boot.good And a verbose dmesg from a failed boot here: http://www.freebsd.org/~wpaul/opteron/dmesg.boot.bad Note that the only major difference is the absence of child devices (the USB host controllers) on bus pci1. The only pattern I've noticed is that 6.0BETA4/amd64 stands a better chance of probing the USB controllers if I do a warm boot following an easlier session with Solaris or FreeBSD/i386 where the controllers were found correctly. For example, when I first did the 6.0BETA/amd64 install, the initial bootstrap from the CD was successful. But once I completed the installation and rebooted to start up the freshly installed system, the USB controllers went AWOL again. This las led me to think that problem might be related to some sort of ACPI fiddling that occurs during shutdown which is not properly un-done during startup. Unfortunately, I can't really prove this. The only evidence I have to support this theory is that when I warm booted the system after capturing the verbose output for dmesg.boot.good shown above, I saw this: http://people.freebsd.org/~wpaul/opteron/dmesg.shutdown These messages seem to be coming from acpi.c. It looks like some devices are being put into the S5 sleep state at shutdown time. I suspect that we are failing to bring them back to S0 mode at startup, resulting in the devices not being found during the enumeration of pci1. Of course I could easily be full of crap, since you could fill a library with what I don't know about ACPI. Hopefully someone who knows more can shed some light on the problem. I captured the AML from the system here: http://www.freebsd.org/~wpaul/opteron/acpi.aml All I know is, it's very frustrating to boot the system up and find myself with a dead console. I've resorted to leaving getty running on one of the serial ports as a failsafe. I'd really like to run FreeBSD/amd64 on this system full time, but I can't really do that until I get this sorted out. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051023044115.7050216A421>