Bug 5247 - Kernel hang at boot if no USB device plugged in
Summary: Kernel hang at boot if no USB device plugged in
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2005-09-13 14:25 UTC by Christian Casteyde
Modified: 2005-10-31 23:34 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.13.1
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg with hang location marked (15.19 KB, text/plain)
2005-09-13 14:26 UTC, Christian Casteyde
Details
lsusb -v output (8.02 KB, text/plain)
2005-09-13 14:27 UTC, Christian Casteyde
Details
lspci -v output, just for case (5.28 KB, text/plain)
2005-09-13 14:27 UTC, Christian Casteyde
Details
new lsusb for 2.6.13 (8.29 KB, text/plain)
2005-09-14 12:08 UTC, Christian Casteyde
Details
lsusb for 2.6.14 without usb-handoff (8.25 KB, text/plain)
2005-09-14 12:09 UTC, Christian Casteyde
Details

Description Christian Casteyde 2005-09-13 14:25:20 UTC
Most recent kernel where this bug did not occur: 2.6.12 
Distribution: Slackware 10.1 
Hardware Environment: Acer Aspire 1511LMI (AMD64 + nForce3 + nVidia card + TMS 
memory card reader) 
Software Environment: kernel 2.6.13.1/glibc 2.3.5 w NPTL/gcc 3.4.4/Xorg 6.8.2. 
 
Problem Description: 
Since 2.6.13-rc4 at least, the kernel doesn't boot anymore on this hardware if 
no device is plugged in in the USB connector. Actually, it boots OK if a 
Logitech wireless mouse with USB receiver plugged in in the first USB port, but 
it hangs just after detecting the third USB port is this receiver is not 
present. 
Anotated output of dmesg with hang location, output of lspci -v and lsusb -v 
provided. 
 
Steps to reproduce: 
Well, I guess this is a USB specific bug with nForce3. Therefore it would be 
possible to reproduce with a nForce3 based card. I also suspected the card 
reader to deadlock before, but I'm not sure anymore.
Comment 1 Christian Casteyde 2005-09-13 14:26:43 UTC
Created attachment 5995 [details]
dmesg with hang location marked

If I plug in the USB receiver in another port, the kernel goes a little
further, but still hangs.
Comment 2 Christian Casteyde 2005-09-13 14:27:12 UTC
Created attachment 5996 [details]
lsusb -v output
Comment 3 Christian Casteyde 2005-09-13 14:27:43 UTC
Created attachment 5997 [details]
lspci -v output, just for case
Comment 4 David Brownell 2005-09-13 18:49:34 UTC
FWIW I just tried 2.6.14-rc1 on an NF3 and it's happy as a clam.
Making the answer to the usual question ("does it work on the
latest_ kernel, and if not send CONFIG_USB_DEBUG logs", with
latest=2.6.14-rc1) question be more informative than usual...

That system is also using the "usb-handoff" boot parameter, and
my hardware looks similar enough that I'm gonna guess that will
help you a lot.

By the way, your version of "lsusb" must be pretty ancient to
not even display the HCD strings, much less the hub descriptors
and state.  Try 0.71 at linux-usb.sf.net ...
Comment 5 Christian Casteyde 2005-09-14 12:07:44 UTC
Effectively, usb-handoff enables the 2.6.13 kernel to boot. 
I tested 2.6.14-rc1 and it seems to work, even without usb-handoff. 
 
For completeness, I post lsusb with recent usbutils (mine was slack 10.1, which 
is not so old after all, I upgraded to current), for both the 2.6.13 kernel 
(with usb-handoff boot) and 2.6.14-rc1. 
 
Thanks a lot, good job! 
CC 
 
Comment 6 Christian Casteyde 2005-09-14 12:08:27 UTC
Created attachment 6023 [details]
new lsusb for 2.6.13
Comment 7 Christian Casteyde 2005-09-14 12:09:40 UTC
Created attachment 6024 [details]
lsusb for 2.6.14 without usb-handoff

both have the mouse receiver plugged in.
Comment 8 Greg Kroah-Hartman 2005-10-05 14:00:17 UTC
So, for 2.6.14-rc3, this works properly?  Good, I'll close this now.
Comment 9 Christian Casteyde 2005-10-31 14:33:13 UTC
Well, I just happen to have the bug with 2.6.14.    
It's a little different now, and more general: now the kernel hangs even if a    
USB device is connected!    
    
Now, I do not think the fact that a device is connected is important or not.    
And I do not think the problem occurs systematically, since sometimes it boots    
without usb-handoff. This bug is a little difficult to reproduce then...    
    
However, I never had the bug with the usb-handoff boot option. There is a    
workaround thereof, but the problem is still here.  
Comment 10 Greg Kroah-Hartman 2005-10-31 23:34:48 UTC
Ok, this sounds like a new bug, let's start over.  Care to open a new bug report
with the needed information for it?

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