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). How reproducible: Always. Steps to Reproduce: 1. Install FC6 x86_64 on a Dell Latitude D620 2. Boot it 3. Enter 'lsusb' Actual results: It hangs and the process is unkillable. Expected results: It should display the USB devices present in the system. Additional info: 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 clue.
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.