Bug 5247

Summary:	Kernel hang at boot if no USB device plugged in
Product:	Drivers	Reporter:	Christian Casteyde (casteyde.christian)
Component:	USB	Assignee:	Greg Kroah-Hartman (greg)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	akpm
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.13.1	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	5089
Attachments:	dmesg with hang location marked lsusb -v output lspci -v output, just for case new lsusb for 2.6.13 lsusb for 2.6.14 without usb-handoff

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?