Red Hat Bugzilla – Bug 221331
uhci_hcd & ehci_hcd loaded too early on Dell D620, hangs lsusb
Last modified: 2007-11-30 17:11:52 EST
Description of problem:
Running /sbin/lsusb on a Dell Latitude D620 results in an unkillable process.
Version-Release number of selected component (if applicable):
FC6 stock kernel with all current (2007/01/03) updates, 2.6.18-1.2869.fc6,
usbutils-0.71-2.1 (although I think it's a kernel bug).
Steps to Reproduce:
1. Install FC6 x86_64 on a Dell Latitude D620
2. Boot it
3. Enter 'lsusb'
It hangs and the process is unkillable.
It should display the USB devices present in the system.
I encountered this while debugging S3 (suspend to RAM) which did not work out of
the box, however I think that is just a symptom.
Before I got lsusb to work I had to
- remove the modules from /boot/initrd-2.6.18-1.2869.fc6.img (now insmod
complains at preboot of course)
- rename the modules in /lib/modules/2.6.18-1.2869.fc6/kernel/drivers/usb/host,
to 'uhci-hcd.ko-DISABLED' resp. 'ehci-hcd.ko-DISABLED'
- boot the machine into X
- login & run a terminal
- run 'insmod /lib/kernel/fc6/kernel/drivers/usb/host/uhci-hcd.ko-DISABLED'
resp. 'ehci-hcd.ko-DISABLED' by hand
lsusb then started showing output, as attached to the bug report.
I created an /etc/rc.d/init.d script that loads/unloads the modules at
'chkconfig 345 97 03', which fixes the problem, confirming that there is
something about the load time of the modules that confuses the system.
I have no idea whether it's flaky hardware that just needs some more time before
initialization, or some strange sort of dependency on other hardware that gets
loaded later in the boot. I will also attach lspci output, maybe that provides a
Created attachment 144742 [details]
Output of lsusb -v, after correction of module load time
Oops, I was unclear -- it's not the whole system that hangs, just the 'lsusb'
command. And some more information: trying to remove the uhci_hcd or ehci_hcd
modules when they were loaded at boot also results in a stuck rmmod process. The
rest of the system continues to work.
Created attachment 144743 [details]
lspci -v output for this D620
Actually, now that I know where to look, I do see this when I boot from the
original initrd.img (transcribed by hand but I think it's accurate):
Red Hat nash version 5.1.19 starting
Reading all physical volums. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
usb 1-2: device not accepting address 2, error -71
2 logical volume(s) in volume group "VolGroup00" now active
Welcome to Fedora Core
Notice the usb 1-2 line. Hope this helps!
I'm taking this but I really can't pay this problem the attention it needs,
sorry. Maybe after the LCA. I'm leaving this in NEW state for now.
Getting sysrq-t would help (with most other processes killed). I could see
where lsusb got stuck specifically -- and also what khubd was doing.
I *finally* found some time today to retest, and of course this problem has gone
away again using the latest kernel (2.6.19-1.2911.fc6). I'll reopen this if I
can confirm it on a new kernel again.
OK. I still think this is fishy with the port hand-over between companion
controllers. Unfortunately, firmware/BIOS is heavily involved...
Next time this happens, I'll need an output of Sysrq-T to see what hangs
in the rmmod.