Bug 221331 - uhci_hcd & ehci_hcd loaded too early on Dell D620, hangs lsusb
uhci_hcd & ehci_hcd loaded too early on Dell D620, hangs lsusb
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-03 16:12 EST by Stijn Hoop
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-14 07:09:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of lsusb -v, after correction of module load time (16.19 KB, text/plain)
2007-01-03 16:12 EST, Stijn Hoop
no flags Details
lspci -v output for this D620 (6.40 KB, text/plain)
2007-01-03 16:15 EST, Stijn Hoop
no flags Details

  None (edit)
Description Stijn Hoop 2007-01-03 16:12:11 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).

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.
Comment 1 Stijn Hoop 2007-01-03 16:12:11 EST
Created attachment 144742 [details]
Output of lsusb -v, after correction of module load time
Comment 2 Stijn Hoop 2007-01-03 16:14:26 EST
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.
Comment 3 Stijn Hoop 2007-01-03 16:15:18 EST
Created attachment 144743 [details]
lspci -v output for this D620
Comment 4 Stijn Hoop 2007-01-03 16:22:26 EST
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!
Comment 5 Pete Zaitcev 2007-01-12 15:40:16 EST
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.
Comment 6 Stijn Hoop 2007-02-14 07:09:29 EST
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.
Comment 7 Pete Zaitcev 2007-02-14 12:39:42 EST
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.

Note You need to log in before you can comment on or make changes to this bug.