cvs commit: src/sys/dev/usb usb.c

[Bill Paul]

>   Log:
>   Don't defer the boot-time exploration of high-speed USB busses.
>   This ensures that we explore EHCI busses before their companion
>   controllers' busses, so that ports connected to full/low speed
>   devices will be properly routed to the companion controllers by the
>   time the OHCI/UHCI exploration occurs.

On the topic of USB, I've noticed a problem lately with my setup that
seems to indicate a race condition somewhere in the ukbd driver.

I have a Sun w2100z box with several USB 2.0 controllers. The system
has two 2.4Ghz Opteron 250 CPUs, and I'm running it in SMP mode. It
uses a Sun type 6 USB keyboard and USB mouse. I also have a Dell LCD
flat screen display, which has a built-in USB hub. I have the display
plugged into one of the Sun's USB ports and the keyboard and mouse
plugged into the display, the idea being to reduce the number of cables
dangling behind my desk.

The thing is, when I power off the Dell monitor, it also powers off
its internal USB hub. This in turn shuts off power to the keyboard and
mouse, which now look as if they've been unplugged. I tend to power
the monitor off when I leave for work in the morning and turn it back
on when I come home. Ideally, the keyboard and mouse should reconnect
once the power is on again, but when I turn the display back on, what
I find is that the kernel has panicked inside ukbd_timeout():

ndis0: link up
ndis0: no matching rate for: 216
uhub2: at uhub1 port 1 (addr 2) disconnected
ukbd0: at uhub2 port 1 (addr 3) disconnected
ukbd0: detached

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xc
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc05aef48
stack pointer           = 0x10:0xe8ff6cb0
frame pointer           = 0x10:0xe8ff6cc0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 53 (swi4: clock sio)
[thread pid 53 tid 100062 ]
Stopped at      ukbd_timeout+0x18:      calll   *0xc(%eax)
db> where
Tracing pid 53 tid 100062 td 0xc50112e0
ukbd_timeout(c08ec4c0) at ukbd_timeout+0x18
softclock(0) at softclock+0x1e7
ithread_loop(c4f7fc00,e8ff6d48,c4f7fc00,c05ff75c,0) at ithread_loop+0x120
fork_exit(c05ff75c,c4f7fc00,e8ff6d48) at fork_exit+0xa4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe8ff6d7c, ebp = 0 ---
db>

It looks as if the ukbd_timeout() routine is not always disabled when
the ukbd driver is detached. I suspect there is a race condition somewhere
that only manifests on SMP, but I haven't been able to track it down.
This is with the 6.0 SNAP002 CD from March 18th. It also happened with
the SNAP001 CD.

-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
=============================================================================