Bug 8742 - USB2 device failure on boot
Summary: USB2 device failure on boot
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2007-07-12 20:17 UTC by Steven Ringwald
Modified: 2009-03-23 11:18 UTC (History)
1 user (show)

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


Attachments
boot text (21.42 KB, text/plain)
2007-07-12 20:19 UTC, Steven Ringwald
Details
dmesg (different boot, same kernel version) (25.37 KB, text/plain)
2007-07-12 20:23 UTC, Steven Ringwald
Details
verbose lspci (12.79 KB, text/plain)
2007-07-12 20:24 UTC, Steven Ringwald
Details
boot msg for 2.6.22.1 (23.54 KB, text/plain)
2007-07-13 11:03 UTC, Steven Ringwald
Details
module load after boot attempt (module blacklisted to avoid initial load) (7.86 KB, text/plain)
2007-07-13 12:32 UTC, Steven Ringwald
Details

Description Steven Ringwald 2007-07-12 20:17:20 UTC
Most recent kernel where this bug did not occur: unknown
Distribution: debian
Hardware Environment: Nexcom NSA-1045 i686 (Pentium 4)
Software Environment: GNU/Linux
Problem Description: When I boot with a USB 2.0 stick connected, the boot will hang, complaining:

usb 3-4: reset high speed USB device using ehci_hcd and address 2               
usb 3-4: reset high speed USB device using ehci_hcd and address 2               
...

until I unplug the device. The problem does not occur when I boot then plug the device in afterwards. I can even unplug and plug it in quickly when it hangs to get past the problem. Curiously, the problem also seems to go away if I plug the device in after the initial boot and reboot without powering down (I can't say this is 100% reliable). The only work-around I have is to disable USB 2.0, which is unacceptable. Plugging in the device after boot is also unacceptable because this is an embedded solution.

I have searched far and wide for any clues as to what the problem is and how to fix it. I have tried compiling the kernel without CONFIG_USB_SUSPEND. I have tried fiddling with usbcore 'schemes'. Nothing thus far has worked. 

The reboot phenomenon seems to indicate that the device or bus isn't powered up or otherwise initialized properly before it's accessed for the first time. 

Using a non-powered USB 2.0 hub does not appear to change the behavior one iota. 

Steps to reproduce:

Boot Linux on a Nexcom NSA-1045 with a Cruzer mini plugged in.
Comment 1 Steven Ringwald 2007-07-12 20:19:47 UTC
Created attachment 12018 [details]
boot text
Comment 2 Steven Ringwald 2007-07-12 20:23:23 UTC
Created attachment 12019 [details]
dmesg (different boot, same kernel version)
Comment 3 Steven Ringwald 2007-07-12 20:24:16 UTC
Created attachment 12020 [details]
verbose lspci
Comment 4 Greg Kroah-Hartman 2007-07-12 20:27:55 UTC
Can you please try a newer kernel version?  2.6.18 is quite old.  Can you try 2.6.22?
Comment 5 Steven Ringwald 2007-07-13 11:01:34 UTC
I grabbed 2.6.22.1, configured, and compiled it (took a while because the SATA options changed). Same problem, same symptoms:

usb 3-4: reset high speed USB device using ehci_hcd and address 2               
usb 3-4: reset high speed USB device using ehci_hcd and address 2          

root@1U:~# uname -a                                                             
Linux 1U 2.6.22 #1 Fri Jul 13 10:36:03 PDT 2007 i686 GNU/Linux  
Comment 6 Steven Ringwald 2007-07-13 11:03:33 UTC
Created attachment 12029 [details]
boot msg for 2.6.22.1
Comment 7 Steven Ringwald 2007-07-13 11:09:37 UTC
I also tried adding acpi=off to the kernel options. It didn't help.
Comment 8 Steven Ringwald 2007-07-13 12:31:34 UTC
I tried blacklisting ehci_hcd then loading it after boot, but I got the same errors when I tried to access the device after loading the module:

root@1U:~# <6>usb 3-4: reset high speed USB device using ehci_hcd and address 2 

Curiously, if I reboot from this point and try loading ehci_hcd manually again, it fails in the same manner. However if, from this point, I take the module off the blacklist and reboot, replug the usb stick on the error, it will access the stick at 2.0 speed. If I reboot AGAIN from this point I don't need to replug the stick and it will run at full speed. 

So to sum up, the only two methods to run the stick at 2.0 speed is to NOT blacklist the module and then either replug the stick on the initial boot (plug the stick in after the initial bus scan, I presume), or reboot with the stick still in.

It will FAIL if I blacklist the module and load the module manually after boot. Unloading the module afterwards allows me to access the stick at 1.0 speed. Loading the module a second time produced the same error.
Comment 9 Steven Ringwald 2007-07-13 12:32:48 UTC
Created attachment 12030 [details]
module load after boot attempt (module blacklisted to avoid initial load)
Comment 10 Steven Ringwald 2007-07-13 12:39:28 UTC
Correction:

The third way to get USB 2.0 speed is to boot with ehci_hcd blacklisted, load ehci_hcd manually, then replug the USB stick.

Unfortunately, none of these three methods allows me to create a kludge/work-around for an embedded system. They all require either replugging the stick or a manual reboot.

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