Comment 295 for bug 85488

Unfortunately, I think the problem here is twofold:

Firstly, the problem doesn't seem to affect *all* USB devices -- simply those who don't conform to usb_suspend, and violate the USB specification*.

Secondly, I think the issue is that there is a workaround -- but both enabling the workaround and not enabling the workaround will cause regressions either way. (In other words, regardless of what is done, _something_ will stop working, give or take.)

*That said, I think that simply not conforming to a specification seems like a ridiculous reason to cause problems for a device, although I don't think the intent was malicious... or intentional for that matter.

As has been noted above, there are workarounds -- recompiling a custom kernel without usb_suspend, or creating and/or installing a program to constantly poll the device, thus preventing usb_suspend from kicking in.

As fishor's post has noted, there is now code in the linux kernel which will disable usb_suspend on devices which have been specified as having the quirk of faulting under this bug. How long it will take for the code to propagate to users is another issue entirely. Considering the 6-month release cycle of Ubuntu, it might not be until October or even next April before the "fixed" code gets to end users -- and even then, it will only help users who A) encounter the problem, B) find out the cause, and C) report the bug before the necessary release/sync deadlines. (If it weren't for the fact that Ubuntu releases every six months, this might have taken even longer than that.) If your device is uncommon, it would be a good idea to investigate avenues for reporting device IDs to the kernel developers so they can fix the problem for you upstream. Even if the real fix takes six to twelve months to get to you, hopefully this particular won't come back to that device for a long, long time once it's fixed properly. (Unfortunately, A workaround, downgrading, or use under an alternate OS/PC might be necessary in the meantime... or perhaps foregoing the device in the case of non-essential devices... Alternatively, users have the option of compiling and running bleeding-edge code, with all of the additional bugs that comes with that decision.)

In either case, a fix is in the works, and will eventually make its way to machines installed with a future version of *buntu.

As Mark noted, Red Hat has a workaround that works for their kernel -- is there anyone who has such a device who can confirm whether that workaround also works on a Ubuntu machine? (This won't fix the problem, but it will make it go away. However, it will also negate any "power savings" for laptop users that would have come with this particular new feature with the kernel.)

1. Open Applications, then Terminal.
2. A box should appear. In the box, type "sudo gedit /boot/grub/menu.lst" (without quotes) and hit enter.
3. Look about halfway down for a line that starts "# defoptions=" (without quotes; NOTE: use the line with ONE "#" symbol)
4. At the end of this line, add a space, then "usbcore.autosuspend=0" (without quotes)
5. Save and quit gedit.
6. In the box you used earlier, type "sudo /usr/sbin/update-grub" and hit enter.
7. Restart your computer.

Kubuntu/KDE users can instead try the following:

Instead of Step 1, hit the K menu and click "Run Command...".
Instead of Step 2, type "sudo kwrite /boot/grub/menu.lst".
In step 6, you'll have to click the K menu and click "Run Command..." again to bring up another box. Note that you won't get any feedback unless you run the command "in a terminal window" (under options) because update-grub is NOT a graphical application... and therefore you should wait about thirty seconds to two minutes for update-grub to do its work before restarting. (Or you can run it in a terminal window and wait for "<Finished>" to appear in the title bar, assuming you don't mind looking at a vibrantly coloured box that flashes text before your eyes.)