USB 1.1 automatic fallback if 2.0 fails

Bug #177430 reported by Pär Lidén
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Wishlist
Unassigned
Nominated for Hardy by Reid Kaufmann
Nominated for Intrepid by Reid Kaufmann

Bug Description

Binary package hint: linux-source

My idea is that if a USB device gets plugged in, and Linux isn't able to initialize it properly at usb 2.0, it should try initializing it with usb 1.1 instead.

I have a problem where some of my usb-ports (the front ports) work only at usb 1.1 speeds. If I plug in lower speed devices, such as my keyboard, it works perfectly from the front ports. But when i connect higher speed devices, such as usb-sticks, or my digital camera, it won't work. It just fails silently. However, if I remove the usb 2.0 support from the kernel (unloading that module, ie sudo rmmod ehci-hcd), and then insert the usb-stick after that, it works, but only at usb 1.1 speeds of course. I am using Ubuntu 7.10 Gutsy Gibbon.

So I think it would be quite nice if Ubuntu could do this:
When a usb 2.0 device device gets connected on a 2.0 capable port (ie one that is connected to an ehci controller), it should of course first try to init it with usb 2.0 (ehci). If that doesn't work, try with usb 1.1 (uhci/ohci), and preferably put up some message to the user that the device is not working at full 2.0 speed. (This is what win xp does.) I think that a lot of users gets confused when their devices just silently fails at some ports of their computer. And if initializing it with uhci/ohci doesn't work either, then pop up some error message then also of course.

I don't know if this is hard to implement, I'm no kernel hacker. I suppose that the fallback itself would be implemented purely in the kernel (thats why I reported this against linux-source), but bringing forth the message to the user would require probably involving at least udev and HAL also.

This is the error message I get when I plug in my usb-stick:

Dec 19 11:47:41 desktopen kernel: [ 5133.285580] usb 5-6: new high speed USB device using ehci_hcd and address 7
Dec 19 11:47:41 desktopen kernel: [ 5133.397338] usb 5-6: device descriptor read/64, error -71
Dec 19 11:47:41 desktopen kernel: [ 5133.612779] usb 5-6: device descriptor read/64, error -71
Dec 19 11:47:41 desktopen kernel: [ 5133.828252] usb 5-6: new high speed USB device using ehci_hcd and address 8
Dec 19 11:47:42 desktopen kernel: [ 5133.939976] usb 5-6: device descriptor read/64, error -71
Dec 19 11:47:42 desktopen kernel: [ 5134.155446] usb 5-6: device descriptor read/64, error -71
Dec 19 11:47:42 desktopen kernel: [ 5134.371765] usb 5-6: new high speed USB device using ehci_hcd and address 9
Dec 19 11:47:42 desktopen kernel: [ 5134.777916] usb 5-6: device not accepting address 9, error -71
Dec 19 11:47:42 desktopen kernel: [ 5134.889652] usb 5-6: new high speed USB device using ehci_hcd and address 10
Dec 19 11:47:43 desktopen kernel: [ 5135.296644] usb 5-6: device not accepting address 10, error -71

I'm pretty sure the cause for me is that the internal cabling to front ports is bad. The two front usb ports are connected via one cable to a 10-pin connector on the motherboard. The back ports, which connect directly to he motherboard, work perfectly.

I've looked at bug #88746, which describes the same symptoms, and the same solution (unloading ehci-hcd). However, in my case, I don't think Linux or the motherboard is to blame, but just the cables, as it works in winxp (but at 1.1 speeds). Maybe this bug would be rated as a feature request then. But implementing this feature would certainly help those people affected by bug #88746, and not computer-savvy enough to unload ehci-hcd. This feature would then provide a workaround for them that at least enables them to use their devices (albeit at low speeds).

Please tell me if you need some clarification, or something else. And thanks for your work in putting together a highly usable operating system.

Daniel T Chen (crimsun)
Changed in linux-meta:
importance: Undecided → Wishlist
Changed in linux (Ubuntu):
status: New → Triaged
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.