The case of the missing USB controllers

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_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================