ehci_hcd module causes I/O errors in USB 2.0 devices

[Al Buntu]

Certain USB devices do not work properly, or do not work at all, while the ehci_hcd module is loaded.

A solution is to unload the ehci_hcd module, which is loaded every time the computer starts, using the command 'sudo modprobe -r ehci_hcd'. This works fine but unfortunatly ehci-hcd is necessary for using USB 2.0, so you lose USB 2.0 features.
Another solution is to disable USB 2.0 through the BIOS setup.

With some devices it is possible to read files normally (ie. copy files from an USB pendrive to the computer), but the device disconnects abrubtly when you start writing data on the device. In some devices it fails after writing a certain amount of data, probably the size of the write cache.

Steps to reproduce:
1. Insert your USB 2.0 device (like a flash drive)
2. If the device is recognised and mounted properly try copying a file to it.
3. Comfirm with the 'dmesg' command that it isn't functioning properly. (I/O errors etc)
4. Remove the USB device
5. Unload ehci_hcd with 'sudo modprobe -r ehci_hcd'
6. Insert your USB device again.
7. Check that everything works. (copy some files, etc.)

A disproportionate number of individuals report Alcor chipsets in the problematic behavior. See:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/62
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/119
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/299
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/397
http://bugzilla.kernel.org/show_bug.cgi?id=ehci_hcd

Noted Workarounds:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372

[Al Buntu (biedermann2)]

I have more informations:
My PC has 4 built-in USB-ports, 2 in front, 2 in the rear. They work without problems with the loaded ehci-modul. if I plug in an USB-stick there he will be recognized.
But:
When I additionally plug in an USB-hub the hub is recognized but after a few seconds my USB-stick is logged off. A message tells me: "Unsafe disc removal..." or something similar.
The same behavior I notice when there is only one usb-hub plugged in and I add a second usb-hub parallel to the first. The second hub "kills" the first.
If there are any additional questions don't hesitate to contact me.

[Al Buntu (biedermann2)]

sometimes it's different:
the at first to the computer connected usb-stick works and the at second added usb-hub doesn't work. I think I get crazy...

[Al Buntu (biedermann2)]

I think there is something wrong with the ehci_hcd module. A few devices work allways and another few work sometimes, some of them only work when connected to the external usb-hub and other devices have to be connected directly to the usb-port iin the pc.
This is my concludion.

[Brian Murray (brian-murray)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description doesn't yet have enough information.
Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command 'uname -a' in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command 'dmesg > dmesg.log' and attach the resulting file 'dmesg.log' to this bug report.
3. Please run the command 'lspci -vvnn > lspci-vvnn.log' and attach the resulting file 'lspci-vvnn.log' to this bug report.
For your reference, the full description of procedures for kernel-related bug reports is available at http://wiki.ubuntu.com/DebuggingKernelProblems . Thanks in advance!

[Al Buntu (biedermann2)]

uname -a:
Linux schlumpf 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux

[magilus (magilus)]

I can confirm this. Everything worked fine with 2.6.17 on Edgy, but with 2.6.20 on Feisty, I can not use any of my usb devices. After demodprobing ehci_hcd, I can use them again.

I have tried this with Feisty on three computers and the problem only appeard on one of them with the following hardware specs: Asus A7N8X-X with NForce 2 chipset.

This is the syslog output when plugging in a USB device having ehci_hcd *loaded* (thus, it does not work)

Mar 7 18:46:03 ubuntu kernel: [ 2809.360819] usb 3-3: device descriptor read/64, error -71
Mar 7 18:46:03 ubuntu kernel: [ 2809.576600] usb 3-3: new high speed USB device using ehci_hcd and address 10
Mar 7 18:46:03 ubuntu kernel: [ 2809.688487] usb 3-3: device descriptor read/64, error -71
Mar 7 18:46:04 ubuntu kernel: [ 2809.904277] usb 3-3: device descriptor read/64, error -71
Mar 7 18:46:04 ubuntu kernel: [ 2810.120055] usb 3-3: new high speed USB device using ehci_hcd and address 11
Mar 7 18:46:04 ubuntu kernel: [ 2810.527642] usb 3-3: device not accepting address 11, error -71
Mar 7 18:46:04 ubuntu kernel: [ 2810.639529] usb 3-3: new high speed USB device using ehci_hcd and address 12
Mar 7 18:46:05 ubuntu kernel: [ 2811.047116] usb 3-3: device not accepting address 12, error -71

(several times)

[magilus (magilus)]

Al Buntu, just noted that you also have a nforce 2 chipset.

Though, I will also attach my outputs.

[magilus (magilus)]

I am going to change the title and the description slightly.

Al Buntu, which mainboard do you have?

[magilus (magilus)]

The guess about nforce2 to blame was wrong. In bug 87386 (now a duplicate of this one) someone has the same problem with a sis chipset.

[Kyle McMartin (kyle)]

Can one of you attach /proc/interrupts both with ehci_hcd loaded, and without?

[Al Buntu (biedermann2)]

My Mainboard:

Asus A7N8X-(X?)
with NForce 2

Greetings,

Al Buntu

Martin Jürgens schrieb:
> I am going to change the title and the description slightly.
>
> Al Buntu, which mainboard do you have?
>
> ** Summary changed:
>
> - my usb devices only work if I do "sudo modprobe -r ehci_hcd"
> + USB devices do not work with nforce 2 based motherboards
>
> ** Description changed:
>
> - the ehci_hcd is loaded every time the computer starts. This is normal
> - and necessary for using usb 2.0 highspeed. But not all usb compontents
> - work if this module has been loaded.
> + USB devices do not work with nforce 2 based motherboards.
> +
> + A solution is to unmodprobe ehci_hcd, which is loaded every time the
> + computer starts. This is normal and necessary for using usb 2.0
> + highspeed.
>
> ProblemType: Bug
> Date: Wed Feb 28 19:34:17 2007
> DistroRelease: Ubuntu 7.04
> Uname: Linux schlumpf 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux
>
>

[magilus (magilus)]

fixed in 2.6.20-10

[magilus (magilus)]

reappeard in 2.6.20-12-generic

[Jared Sutton (jpsutton)]

I'm having the same issue here on a Thinkpad T40 and the Feisty Beta (2.6.20-12-generic). For now, I've put "modprobe -r ehci_hcd" in /etc/rc.local.

[Mika Kukkonen (mikukkon)]

I'm also having this same issue with current Feisty, i.e. none of my USB memory sticks are recognized after boot, but do work after doing "sudo modprobe -r ehci_hcd" (have not looked at the speed, though).

Doing "sudo lsusb" (without the modprobe workaround) causes following log:
usb 3-2: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
usb 3-2: reset high speed USB device using ehci_hcd and address 17
usb 3-2: reset high speed USB device using ehci_hcd and address 17
usb 3-2: reset high speed USB device using ehci_hcd and address 17
usb 3-2: reset high speed USB device using ehci_hcd and address 17
usb 3-2: USB disconnect, address 17
usb 3-2: new high speed USB device using ehci_hcd and address 18
usb 3-2: new high speed USB device using ehci_hcd and address 19
usb 3-2: new high speed USB device using ehci_hcd and address 20
usb 3-2: new high speed USB device using ehci_hcd and address 21
usb 3-2: new high speed USB device using ehci_hcd and address 22

After the modprobe workaround, I get immediately this:
ehci_hcd 0000:00:02.2: remove, state 4
usb usb3: USB disconnect, address 1
usb 3-1: USB disconnect, address 2
ehci_hcd 0000:00:02.2: USB bus 3 deregistered
ACPI: PCI interrupt for device 0000:00:02.2 disabled
usb 1-1: new full speed USB device using ohci_hcd and address 3
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-2: new full speed USB device using ohci_hcd and address 4
usb 1-2: configuration #1 chosen from 1 choice
scsi8 : SCSI emulation for USB Mass Storage devices
scsi 8:0:0:0: Direct-Access USB 2.0 Flash Drive 1.00 PQ: 0 ANSI: 2
SCSI device sdd: 2058752 512-byte hdwr sectors (1054 MB)
sdd: Write Protect is off
device sdd: 2058752 512-byte hdwr sectors (1054 MB)
sdd: Write Protect is off
sdd: sdd1
sd 8:0:0:0: Attached scsi removable disk sdd
sd 8:0:0:0: Attached scsi generic sg3 type 0

And the device gets shown on desktop etc.

More info available on request.

[magilus (magilus)]

Works for me with 2.6.20-13-generic again. What about you?

[Mika Kukkonen (mikukkon)]

Did a reboot, and it still does not work with 2.6.20-13-generic. Had
to do "sudo depmod -a" to get a workaround working, even. Same logs.

--MiKu

On 3/26/07, Martin Jürgens <email address hidden> wrote:
> Works for me with 2.6.20-13-generic again. What about you?
>
> --
> USB devices are not recognized when having ehci_hcd modprobed
> https://launchpad.net/bugs/88746
>

[Jared Sutton (jpsutton)]

This page at ThinkWiki suggests that this may be a hardware issue (failing hardware): http://thinkwiki.org/wiki/Problem_with_USB_2.0

I'll test 2.6.20-13-generic to see if that solves it and I'll post back...

[Mika Kukkonen (mikukkon)]

Mine is dual boot machine, and USB works fine under Windows...

--MiKu

On 4/5/07, Jared Sutton <email address hidden> wrote:
> This page at ThinkWiki suggests that this may be a hardware issue
> (failing hardware): http://thinkwiki.org/wiki/Problem_with_USB_2.0
>
> I'll test 2.6.20-13-generic to see if that solves it and I'll post
> back...
>
> --
> USB devices are not recognized when having ehci_hcd modprobed
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jared Sutton (jpsutton)]

Still the same issue with 2.6.20-13-generic here. :(

[Mika Kukkonen (mikukkon)]

And with 2.6.20-14-generic too.

--MiKu

On 4/6/07, Jared Sutton <email address hidden> wrote:
> Still the same issue with 2.6.20-13-generic here. :(
>
> --
> USB devices are not recognized when having ehci_hcd modprobed
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[John Zero (johnzero)]

Same issues. The command:

modprobe -r ehci_hcd

"helped" somewhet.

Linux ewa 2.6.20-14-386 #2 Mon Apr 2 20:34:35 UTC 2007 i686 GNU/Linux

Asus A7N8X with NForce2 chipset

[stephg (stephg)]

Same issue on Dapper.

My Lexar Card reader RW022 does not work anymore after kernel update on Dapper (Linux hyperion 2.6.15-28-386 #1 PREEMPT Thu Feb 1 15:51:56 UTC 2007 i686 GNU/Linux)

Works perfectly with 2.6.15-27

I also have an Asus A7N8X with NForce2 chipset

[TheLimper (thelimper-rogers)]

FYI:

I've noticed strange problems after upgrading to Feisty from Edgy with my USB devices on both my main PC and IBM R51 laptop.
Until I found this thread I couldn't figure out what was going on but I unmodprobing ehci_hcd restored things to how they functioned in Edgy.
I don't think this is bug is restricted to NFORCE 2 as my main PC is an NFORCE4 and the IBM R51 laptop is of course whatever they use.

The main thing I noticed on my NFORCE4 PC was during the boot my USB Creative labs LIVE! 24 External was being recognized but the 'blue light' was not powering on as was normal and I was getting strange sound problems.
After removing ehci_hd everything returned to normal.
I think something is definately off with the ehci_hcd module.

[Mika Kukkonen (mikukkon)]

Just for the record, I tried the old_scheme_first trick recommend somewhere:

# echo Y > /sys/module/usbcore/parameters/old_scheme_first

and that did not help either :-(

--MiKu

[John Zero (johnzero)]

Not much ideas, but some description of what the old_scheme_first thing is can be read here:
http://www.spinics.net/lists/usb/msg02644.html
Another (old) thread:
http://www.fedoraforum.org/forum/archive/index.php/t-30868.html

It seems strange that this might be an old bug that creeped back was not present in the previous Ubuntu version. (Or maybe an udev modfiication?)

[Mika Kukkonen (mikukkon)]

I dug into kernel code a bit, and looked where does the
/var/log/kern.log messages come (at least in my case):

usb 3-2: new high speed USB device using ehci_hcd and address 11
usb 3-2: device descriptor read/64, error -71
usb 3-2: device descriptor read/64, error -71

As far I as I can read the code, that -71 is EPROTO and it gets set by
the following
code in usb_get_descriptor() in file drivers/usb/core/message.c :

  result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
    USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
    (type << 8) + index, 0, buf, size,
    USB_CTRL_GET_TIMEOUT);
  if (result == 0 || result == -EPIPE)
   continue;
  if (result > 1 && ((u8 *)buf)[1] != type) {
   result = -EPROTO;
   continue;
  }

Not much help there. Do others have the same error code/message in
their kern.log?

[stephg (stephg)]

It seems that this bug is now present in the previous Ubuntu version.

As I said in my previous comment, my card reader that used to work with kernel 2.6.15-27 does not work anymore with 2.6.15-28 on Dapper.

I can make it work by unloading the ehci module. It really seems to be the same problem. The dmesg error messages are very similar too.

[John Zero (johnzero)]

Mika please read the attachments (dmesg.log), too.
Yes, everyone's having the same problem!

Based on the links I included, too, it seems that when the ehci_hcd module is not present, USB works in USB 1.1 mode. In USB 1.1 mode, the problem isn't there.
Of course, USB 1.1 is dead slow for many external devices.

I'm still not sure why it has worked in Dapper. Maybe the ehci driver worked well with NForce, but something has changed, breaking it? Or maybe it IS the 'old_scheme_first' that has changed. Not sure.

[ingo (rum-topf)]

Problem persists in Feisty

ingo@dicker:~$ lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 746 Host (rev 02)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL Media IO] (rev 25)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
00:09.0 Mass storage controller: Promise Technology, Inc. PDC20375 (SATA150 TX2plus) (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)

[Robert North (russetrob)]

I too am having this problem in feisty, since install.
Current kernel: 2.6.20-15-generic.

Will attach log file, and hardware info later.

[Robert North (russetrob)]

It might be worth noting that I only have this problem at boot, and only with USB hubs.
Other devices connected directly to PC work fine.

If I plug/unplug the hub, all attached devices are seen correctly, and work fine.

Also hardware submission id for this machine is (without working USB devices): 81f3577cb048901b6de9030bd0cd86d5

[rai4shu2 (rai4shu2)]

In my case, only the Multi-Card Reader USB 2.0 seems to act up with ehci. It can interface with 4 different size cards which are then seen as 4 SCSI devices, and is connected by USB internally so I have no way to replug it after booting.

[Alwin Garside (yogarine)]

The description of this bug should be changed since it most certainly isn't restricted to nForce mainboards.

I have the same problem with this board:
http://www.asrock.com/mb/overview.asp?Model=M266A

I will post my logs, etc, later.

[Francesco Potortì (pot)]

I have an old mainboard with a card reader attached to one USB port. Since when I upgraded to Feisty, I have not been able
to read two of my USB sticks, which I could read before Feisty and which I can read on a different PC with Feisty. However,
the card reader works and moreover I can read an MP3 reader with a USB interface. The "modprobe -r ehci_hcd" trick works
for me. If, after trying unsuccessfully to read a USB stick, I launch usbview, it hangs and the kernel logs show repeatedly
this:
May 6 21:33:12 localhost kernel: [ 648.336000] sde : READ CAPACITY failed.
May 6 21:33:12 localhost kernel: [ 648.336000] sde : status=0, message=00, host=1, driver=00
May 6 21:33:12 localhost kernel: [ 648.336000] sde : sense not available.
May 6 21:33:12 localhost kernel: [ 648.337000] sde: Write Protect is off
May 6 21:33:12 localhost kernel: [ 648.337000] sde: Mode Sense: 00 00 00 00
May 6 21:33:12 localhost kernel: [ 648.337000] sde: assuming drive cache: write through
May 6 21:33:12 localhost kernel: [ 648.338000] sde : READ CAPACITY failed.
May 6 21:33:12 localhost kernel: [ 648.338000] sde : status=0, message=00, host=1, driver=00
May 6 21:33:12 localhost kernel: [ 648.338000] sde : sense not available.
May 6 21:33:12 localhost kernel: [ 648.339000] sde: Write Protect is off
May 6 21:33:12 localhost kernel: [ 648.339000] sde: Mode Sense: 00 00 00 00
May 6 21:33:12 localhost kernel: [ 648.339000] sde: assuming drive cache: write through

Kernel is 2.6.20-15-lowlatency, mainboard is an anonymous PM-999BA-AVS, chip VIA KM133+686B, AGP 4x,
integrated Savage4 (disabled), FSB 266 MHz, ATA 100, AMD Duron 1000 MHz, Radeon 9250 128 MB, USB audio
Creative.

In the attached kern log, I attach the USB stick at May 6 21:45:10, which fails. I then remove the ehci_hcd module and
try again at May 6 21:51:45, when it works.

[Robert North (russetrob)]

Ok, here's my kernel logs.

Initially it shows the hubs failing.

At time [ 6758.049237] I unplug/plug the hub, and all attached deices wok properly.

[Robert North (russetrob)]

Here are the PCI logs.
No change before/after plug/unplug of USB devices.

[Robert North (russetrob)]

Here are the lsusb just after boot.
Hubs are missing, and connected devices missing.

[Robert North (russetrob)]

Here is the lsusb with the devices now working.

[Francesco Potortì (pot)]

Until this problem is corrected, you just edit you /etc/rc.local and, *before* the line 'exit 0', you add this line:
 modprobe -r ehci_hcd

[xens (r-aviolat)]

Same problem here!

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94540

[Paulo Pereira (pjpereira)]

i think i have the same problem with feisty and an hp laptop working with 64bits.
to boot i need noapic and noirqdebug and even so, i can only boot 50% of the times.
this is a bit frustrating. with 32bits it worked fine. with edgy i also add problems and needed noapic to boot even on 32bits.

[Robert North (russetrob)]

I wasn't sure if the earlier reports of the old_before_new usbcore property not working were due to the property not being set early enough in the boot process.

I thought I'd try adding the old_before_new to my intramdisk image.
Successfully applied the property via file in /etc/modprobe.d, but didn't see any change in behaviour.
Have confirmed property is set via the /sys/modules/usbcore/properties

[Robert North (russetrob)]

Correction:
I should say "old_scheme_first" when is said "old_before_new" in my last post.

[Seppe vanden Broucke (macuyiko)]

Confirmed. One of my USB sticks couldn't be detected. After unprobing ehci_hcd, it worked fine. Strangely enough, my other USB sticks work fine with ehci_hcd.

[ingo (rum-topf)]

kernel update to 2.6.20-15-generic apparently fixed the problem - all usb2 devices are recognized properly again (my lspci output is listed above)

[John Zero (johnzero)]

I have a USB HUB. Some things don't really work well if plugged into the HUB, eg. my Canon scanner only works in USB 1.1, not 2.0 mode (that is, without the ehci_hcd module). Maybe there's a problem with ehci_hcd and this HUB?

lsusb says my HUB is:
Bus 001 Device 004: ID 05e3:0606 Genesys Logic, Inc.

[Robert North (russetrob)]

ingo, 2.6.20-15 is the version that doesn't work for me.
What was the latest non-functioning version for you?

[ingo (rum-topf)]

2.6.18-11-generic and -386. Everything worked fine until 2.6.8.10 though

[Miguel Diago (mdm)]

I can confirm this in
Linux ubuntu 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/Linux

In my case I can't use a 250GB Freecom Classic HD without unmodprobing ehci_hcd.

[wannes (wannes)]

I filed bug #87386 (now a duplicate). My workaround used to be to blacklist the ehci_hcd module. That way my USB-stick and cardreader worked (at a slower speed, but they got recognised).

Now even blacklisting doesn't work anymore; I have to manually modprobe -r ehci_hcd after every reboot.

Linux duvel 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

[Nguyen Tam Chinh (unixvn)]

I got usb flash and card reader trouble under fresh install of 7.04. And even an update to a newer kernel 2.6.21-5 does not help. modprobe -r ehci_hcd gives no effect for me.
Dmesg is included. This is a notebook Fujitsu-Siemens PA 1510 (Turion X2).

Linux unix 2.6.22-4-generic #1 SMP Thu May 17 05:04:57 GMT 2007 x86_64 GNU/Linux

[Tadzik (tadzik47)]

The same by me.
Leadtek K7NCR18G (nForce2), Athlon XP 3k+, 1.25GB RAM

[url=http://wklej.org/id/f3a275e2fd]kern.log[/url]
[url=http://wklej.org/id/b968cd68e4]lspci[/url]

lsusb:
Bus 003 Device 003: ID 058f:6362 Alcor Micro Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 008: ID 0dc6:5000 Precision Squared Technology Corp.
Bus 001 Device 007: ID 0dc6:5000 Precision Squared Technology Corp.
Bus 001 Device 006: ID 046d:c01e Logitech, Inc. MX518 Optical Mouse
Bus 001 Device 001: ID 0000:0000

uname -a
Linux tadzik-desktop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

[brim4brim (maherb)]

I have same device and problem as user in this post:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/59

250GB Freecom Classic Series HDD.

Works perfectly in Windows XP. Thought it was broken at first, had a heart attack. Just posting here to make numbers noticing the issue known.

The command mentioned (and pasted below) does nothing to solve the problem. First time I ran it, the blue light flashed on once on the drive but then nothing. It does the same at boot.
modprobe -r ehci_hcd

[brim4brim (maherb)]

Here is my error when I run the modprobe command above. I've also installed pmount which I found in a googled thread on a forum that said solved the problem and ran the modprobe command but nothing but this message in attached file.

[Carsten Schurig (cs42)]

FYI, exactly the same this error appeared for me because of failing hardware! Linux just recognized it earlier than Windows XP. In my case it was an USB CF card reader which was operational in just 25% of the time after upgrading from Edgy to Feisty. But after a while Windows XP showed a similar behaviour.

Maybe Linux is more sensitive to failing hardware here (let it the board or the USB devices). At least I wouldn't be too sure that it isn't some hardware problem!

[brim4brim (maherb)]

I actually was coming here to post that I've had this problem since Hoary (I think, might have been Dapper). It worked on the Live CD of Dapper but not the installed version.

I think its not a hardware failure but maybe a problem with the manufacturers setup of the HDD. I've not had the HDD as long as I've had Ubuntu installed.

Either my HDD is failing since I got it or its a problem with Freecom drive setup or its a problem with Ubuntu.

[Alwin Garside (yogarine)]

@brim4brim:

Hoary and Dapper were released more then a year apart, wich one is it? Also please attach some more information (Like the results of dmesg and lsusb) so we can see if your case is relevant at all. Also try if unmodprobing ehci-hcd helps. (sudo modprobe -r ehci-hcd)

[brim4brim (maherb)]

Hoary Hedgehog I'm pretty sure because it worked on the Live CD on Dapper and I though, hurray its fixed but then I had the problem when I installed it and have had it with all installed releases since (have not tried it on a Live CD again though).

the unmodprobing command does nothing. I posted the output from that above in an earlier post (4 posts up) as it runs, gives output then hangs. Sometimes it just hangs and never gives back control of terminal until I press Ctrl+C.

I've run those two commands and will attach them now.

[brim4brim (maherb)]

and my lsusb output. I should add that my Archo's MP4 player works in Linux mounting as a HDD.

My laptop is a Dell Latitude D810 with ATI X600 graphics card (proprietary driver installed but it wasn't in some of the previous versions as it was unsupported).

[uradar (andreurigogost)]

I have an A7N8X (chipset nforce 2) and problems still persist using kernel 2.6.20-16-386. If booting with the dapper (6.06.1) CD usb devices work fine. Thanks for your effort.

[Tadzik (tadzik47)]

Problem persist on Kernel 2.6.21-gentoo-r2 #2 PREEMPT Mon Jun 4 17:09:50 CEST 2007 i686 AMD Athlon(tm) XP 3000+ AuthenticAMD GNU/Linux.
Poblem not persist on kernel generated by genkernel...

[BobMcD (mcbobbo)]

Disclaimer: This could be COMPLETELY UNRELATED, but...

I solved this same persistant problem on my system (Feisty 2.6.20-16) by using the instructions at this link:

http://www.vmware.com/community/message.jspa?messageID=575305#575305

Specifically:

<quote>
Found this information from another post in the Ubuntu Linux forums, maybe it is relevant in other linux ditros...

USB Devices Are Not Available on Some Linux hosts, the VM > Removable Devices > USB Devices Menu Is Empty

In short, the problem was Ubuntu not mounting USBFS to /proc/bus/usb.

Solution:
sudo mount -t usbfs none /proc/bus/usb

and add the following line in the /etc/fstab file:
usbfs /proc/bus/usb usbfs auto 0 0
</quote>

[Robert North (russetrob)]

Usbfs trick on my system doesn't work.

On my system the usbfs appears properly mounted.
Tried adding the exact line into fstab, with no change.

[Robert North (russetrob)]

tried adding acpi=off and noapic (but not both at the same time)
No change, still failing

Tadzik:
Could you look at what the changes between the basic 2.6.21 kernel, from gentoo, and the genkernel version.
Maybe there's a conifgure option change?

[uradar (andreurigogost)]

The usbfs trick neither worked for me. :-(

[biffster (biffster)]

No go on usbfs here. I also tried building a kernel based off the Ubuntu kernel, turning off all of the Experimental options related to ehci. No joy.

[Tadzik (tadzik47)]

Hi.
I'm sorry.
This was problem with dmesg on LiveCD... When genkernel is loaded problem persist, but info is only in /var/log/messages...

[Robert North (russetrob)]

Ok thanks for tyring Tadzik.

I've also tried to compile the 2.6.22 kernel that's slated for next version of ubuntu, and still had USB problems.

[Robert North (russetrob)]

This bug suggests a possible soloution.
http://bugzilla.kernel.org/show_bug.cgi?id=7932

It suggests that some of these problems may be due to suspend operations occuring.

I'm building a kernel without power management, as a first test.

Will try one with CONFIG_USB_SUSPEND unset, and rest of power management enabled if that works.

Also, here are some patches that might be relevant:
http://thread.gmane.org/gmane.linux.usb.devel/54630

Finally, here's a list of possible kernel bugs that might match this Ubuntu bug:
http://bugzilla.kernel.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Drivers&component=USB&long_desc_type=substring&long_desc=error+-71&kernel_version_type=allwordssubstr&kernel_version=&bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=REJECTED&bug_status=DEFERRED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&regression=both&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

[Robert North (russetrob)]

Initial tests suggest that turning off power management works.
Have not yet booted into X, and modules outside kernel package not installed.....
but looking good.
Tomorrow I'll try full power management, but without CONFIG_USB_SUSPEND
..... unless someone wants to beat me to it ;)

[Tadzik (tadzik47)]

Well...
This option was not-set in my kernel, because is experimental... I try enabled it. :)

[Robert North (russetrob)]

Tadzik, I'm intending to *disable* it.
The fact that your kernel had it disabled ans still fails doesn't bode well.

[Robert North (russetrob)]

CONFIG_USB_SUSPEND does indeed work (Or appears to so far)
Will now try to build the extra modules I have installed and do a proper boot.
I'll be putting up kernel logs with some debug messages turned on soon, so demonstrate the differences in the boot process.

[biffster (biffster)]

Interesting. I thought I had turned off all of the Experimental stuff for USB, but somehow missed CONFIG_USB_SUSPEND. I am compiling a new kernel with CONFIG_USB_SUSPEND disabled right now. Hopefully I can test this out tonight.

[biffster (biffster)]

Well, that didn't work for me. The error changed:

[ 2669.784934] usb 7-5: new high speed USB device using ehci_hcd and address 63
[ 2670.504219] usb 7-5: new high speed USB device using ehci_hcd and address 64
[ 2676.850928] usb 6-2.3: new high speed USB device using ehci_hcd and address 97
[ 2677.681842] hub 6-2:1.0: Cannot enable port 3. Maybe the USB cable is bad?

Now the interesting bit is that this only happens for multi-function devices. In my case, this is happening on two USB card readers (both work fine in Windows; one used to work fine in Ubuntu on this box before I upgraded, the other is brand new). I have no problems with my iPod Nano, webcam, Palm T|X, nor Olympus camera. Some of these are obviously low-speed devices, but the iPod should be using ehci_hcd, and it's working without a problem.

I've also tried multiple cables. Also, the same cable that was used on one of the card readers worked flawlewssly to connect the Olympus camera.

[robertocravero (roberto-cravero)]

Ubuntu 7.04 - Kernel 2.6.20.16 - Acer Travelmate 3040

After last upgrade I made 2 days ago, now it's working quite well !!!

[rai4shu2 (rai4shu2)]

Nothing fixed in Feisty here. In fact, I don't think the kernel has been modified in a couple weeks.

$ apt-cache policy linux-headers-2.6.20-16
linux-headers-2.6.20-16:
  Installed: 2.6.20-16.29
  Candidate: 2.6.20-16.29
  Version table:
 *** 2.6.20-16.29 0
        500 http://security.ubuntu.com feisty-security/main Packages
        100 /var/lib/dpkg/status

[Robert North (russetrob)]

I can finally confirm that my USB devices are working.
The devices that are working are 3 usb ports, printer, keyboard , mouse and wacom tablet.
I have also compiled the restricted modules package agianst my modified kernel.
I've attached a diff of the kernel config between non-functioning, and functioning kernel.

[Robert North (russetrob)]

Here's the kernel log for my new successful kernel.

(Will follow soon with kernel log for standard failing kernel, with debugging msgs enabled.)

[Tadzik (tadzik47)]

2.6.21-gentoo-r3 seems to be working with Your settings. :)
Thx

[Andrew Straw (astraw)]

With the kernel 2.6.20-16-generic I still get the problem, and if I rmmod ehci_hcd, it goes away.

[Robert North (russetrob)]

Here's the diff for the kernel config of the failing kernel.
Only changes from generic kernel are debug messages.

[Robert North (russetrob)]

Here's the kernel log of the failing kernel with usb and other debugging enabled (see last message for what was enabled)

Things start going wrong after this line:
     Jun 25 23:40:12 rob-desktop kernel: [ 37.446489] usb 3-4: usb auto-suspend.

And that's about all I can do.

[Andrew Straw (astraw)]

Please ignore my posting from a few hours ago. The problem (disconnecting USB device) reappears after a few minutes.

[Troy James Sobotka (troy-sobotka)]

This is happening here on a 32 bit Ubuntu system yet again.

USB fails to auto detect digital camera and the card reader.

Ubuntu 7.04 - Kernel 2.6.20.16 386.

[Troy James Sobotka (troy-sobotka)]

uname -a:

Linux 32bit 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Markus Kienast (elias1884)]

Everything worked for me until the last kernel upgrade to 2.6.20-16-generic 2.6.20-16.29. Now, when I plug in my printer HP 3100 I get these messages:

[ 223.192000] usb 5-3: new high speed USB device using ehci_hcd and address 6
[ 234.736000] usb 5-3: device not accepting address 6, error -110

[Markus Kienast (elias1884)]

When ehci_hcd module is removed I get the following messages:

[ 2166.112000] scsi3 : SCSI emulation for USB Mass Storage devices
[ 2166.112000] usb-storage: device found at 4
[ 2166.112000] usb-storage: waiting for device to settle before scanning
[ 2171.112000] usb-storage: device scan complete
[ 2171.116000] scsi 3:0:0:0: Direct-Access HP Photosmart C3180 1.00 PQ: 0 ANSI: 2
[ 2171.120000] sd 3:0:0:0: Attached scsi removable disk sdb
[ 2171.120000] sd 3:0:0:0: Attached scsi generic sg2 type 0

As soon as I modprobe ehci_hcd:
[ 2185.748000] drivers/usb/class/usblp.c: usblp0: removed
[ 2509.324000] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 18
[ 2509.324000] PCI: Setting latency timer of device 0000:00:1d.7 to 64
[ 2509.324000] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[ 2509.324000] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
[ 2509.324000] ehci_hcd 0000:00:1d.7: debug port 1
[ 2509.324000] PCI: cache line size of 32 is not supported by device 0000:00:1d.7
[ 2509.324000] ehci_hcd 0000:00:1d.7: irq 18, io mem 0x20000000
[ 2509.328000] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[ 2509.328000] usb usb5: configuration #1 chosen from 1 choice
[ 2509.328000] hub 5-0:1.0: USB hub found
[ 2509.332000] hub 5-0:1.0: 8 ports detected
[ 2509.404000] usb 2-1: USB disconnect, address 4
[ 2509.772000] usb 5-3: new high speed USB device using ehci_hcd and address 2
[ 2510.772000] ehci_hcd 0000:00:1d.7: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
[ 2521.316000] usb 5-3: device not accepting address 2, error -110
[ 2521.428000] usb 5-3: new high speed USB device using ehci_hcd and address 3
[ 2532.972000] usb 5-3: device not accepting address 3, error -110
[ 2533.084000] usb 5-3: new high speed USB device using ehci_hcd and address 4
[ 2543.508000] usb 5-3: device not accepting address 4, error -110
[ 2543.620000] usb 5-3: new high speed USB device using ehci_hcd and address 5
[ 2554.044000] usb 5-3: device not accepting address 5, error -110

[Markus Kienast (elias1884)]

In case you are wondering about which hardware I am having.

[nusigmaforce (doctorcelebro)]

USB Maxtor Onetouch II 300GB works perfectly on Edgy and WinXP. Ever since I went to Feisty I can't see my USB hard drive on my desktop, and what drive me nuts is that I could see it on Edgy without any tweaking whatsoever and in Windows XP too. I tested Gusty and the problem is still there. I have the following thread open in ubuntuforums.org.

http://ubuntuforums.org/showthread.php?p=2993863#post2993863

If you need more information please let me know. Thanks.

[Sitsofe Wheeler (sitsofe)]

Could folks seeing problems please try testing from a Gutsy liveCD ( http://cdimage.ubuntu.com/daily-live/current/ ). If things are no better can you use the workaround described in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85488/comments/363 ? *Only if* this makes a difference can you post what you did along with the output of
lsusb
for the device in question (along with a description of what that device is) over in Bug #85488 . Thanks!

[Robert North (russetrob)]

Sitsofe:
Could you clarify when you want us to report in Bug #85488?

Do you want us to report in that bug if our USB devices work after trying the gutsy live cd, and *only* the live CD?

Do you want us to to report in the bug when the only combination that fixes the bug is the Gutsy live CD *and* the workaround?

Now, as soon as I have time will go of and to the test.
Thanks for looking at this bug.

[Sitsofe Wheeler (sitsofe)]

Robert:
My bad I will to explain further (but it is effectively only your later suggestion):

Please report in Bug #85488 IF the bug is still there when you use a gutsy live cd or a gutsy install (although just using the live cd will be fine) AND using the workaround described in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85488/comments/363 resolves the issue.

[biffster (biffster)]

On Sun, Jul 22, 2007 at 07:58:48PM -0000, Sitsofe Wheeler wrote:
> Could folks seeing problems please try testing from a Gutsy liveCD

I tried, but k3b said that there wasn't enough space on my CD to burn the iso
to. I forced k3b to try, but the burn failed. I still tried to boot from the
resultant CD, and I did get up to a gdm screen. But the Gnome desktop
wouldn't load, and switching over to a console, I couldn't get any apps to
run at all. Not even an 'ls'.

--
Michael Fierro <email address hidden>
Y! Messenger: miguelito_fierro AIM: mfierro1
http://biffster.org http://weightjournal.com
--
Abstainer, n.:
 A weak person who yields to the temptation of denying himself a
 pleasure.
  -- Ambrose Bierce, "The Devil's Dictionary"

[Sitsofe Wheeler (sitsofe)]

biffster:
Hmm. Looks like you need 700Mbyte sized CDs to use those ISOs...

[biffster (biffster)]

On Wed, Jul 25, 2007 at 05:58:37PM -0000, Sitsofe Wheeler wrote:
> biffster:
> Hmm. Looks like you need 700Mbyte sized CDs to use those ISOs...

I do have 700mb CDs. The iso that day was 722mb. k3b was able to squeeze
711mb onto the disc before it failed.

--
Michael Fierro <email address hidden>
Y! Messenger: miguelito_fierro AIM: mfierro1
http://biffster.org http://weightjournal.com
--
ASCII:
 The control code for all beginning programmers and those who would
 become computer literate. Etymologically, the term has come down as
 a contraction of the often-repeated phrase "ascii and you shall
 receive."
  -- Robb Russon

[DarkDespair5 (darkdespair5)]

I have the same problem. My problem affects large external hard drives (Western Digital 200GB, Maxtor OneTouch III TB). Small devices like flash drives work for me most of the time. Unloading ehci_hcd always works for me. Note: Sometimes my external HDs will load. Sometimes they don't. My other USB devices have never had problems. It's interesting that devices affected don't draw power. (My IPod connected to a Windows computer to which I forcefully mangled the drivers to diagnose something still charged)

xxxxxxxxxxxx@ThE-ShAdOw:~$ sudo lspci
00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6)
00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4)
00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2)
00:06.1 Modem: nVidia Corporation nForce3 Audio (rev a2)
00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5)
00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3)
02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)

[DarkDespair5 (darkdespair5)]

Here is my dmesg output, with before and after lines inserted to show time.

[midnightflash (midnightflash)]

I can confirm this problem too.

NForce2

System: Uptodate Gutsy

$ uname -a
Linux ubuntu 2.6.22-11-generic #1 SMP Fri Sep 7 05:07:05 GMT 2007 i686 GNU/Linux

$ tail -f /var/log/messages
[...]
Sep 10 19:17:58 ubuntu kernel: [23866.013450] usb 3-4: reset high speed USB device using ehci_hcd and address 7
Sep 10 19:18:37 ubuntu kernel: [23904.138209] usb 3-4: reset high speed USB device using ehci_hcd and address 7
Sep 10 19:19:11 ubuntu kernel: [23938.866105] usb 3-4: reset high speed USB device using ehci_hcd and address 7
[...]

$ lsusb
Bus 003 Device 007: ID 152d:2338
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 002: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

$ lspci
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
00:01.0 ISA bridge: nVidia Corporation MCP2A ISA bridge (rev a3)
00:01.1 SMBus: nVidia Corporation MCP2A SMBus (rev a1)
00:02.0 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation MCP2A USB Controller (rev a2)
00:04.0 Bridge: nVidia Corporation MCP2A Ethernet Controller (rev a3)
00:06.0 Multimedia audio controller: nVidia Corporation MCP2S AC'97 Audio Controller (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP2A PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation MCP2A IDE (rev a3)
00:0b.0 IDE interface: nVidia Corporation nForce2 Serial ATA Controller (rev a3)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
01:00.0 VGA compatible controller: nVidia Corporation NV40 [GeForce 6800] (rev a1)
02:08.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A [FM801] (rev b2)
02:08.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game port] (rev b2)
02:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
02:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)

[midnightflash (midnightflash)]

Sorry... I don't know if Baltix is affected... Just forgot to hit the dropdown to Ubuntu.

[Henrik Nilsen Omma (henrik)]

Reproduced on Gutsy, moving task properties.

[Henrik Nilsen Omma (henrik)]

Too late for Feisty.

[nusigmaforce (doctorcelebro)]

Henrik:
Thanks for the updates. Will it be fixed on Gusty? I'm still using Edgy on one of my systems because it doesn't work on Feisty. I'm looking forward to Gusty working with my USB external back-up HDD. Thanks,

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Tue, 11 Sep 2007 19:07:53 +0000
> Subject: [Bug 88746] Re: USB devices are not recognized when having ehci_hcd modprobed
>
> Too late for Feisty.
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Status: Confirmed => Won't Fix
>
> --
> USB devices are not recognized when having ehci_hcd modprobed
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
More photos; more messages; more whatever – Get MORE with Windows Live™ Hotmail®. NOW with 5GB storage.
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_5G_0907

[Andrew Straw (astraw)]

On gutsy, one can disable the usb suspend by the following command:

echo -n -1 > /sys/module/usbcore/parameters/autosuspend

That fixes things for me.

[nusigmaforce (doctorcelebro)]

Andy,
I'll give that a try. Thanks,

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Sat, 15 Sep 2007 17:37:42 +0000
> Subject: [Bug 88746] Re: USB devices are not recognized when having ehci_hcd modprobed
>
> On gutsy, one can disable the usb suspend by the following command:
>
> echo -n -1 > /sys/module/usbcore/parameters/autosuspend
>
> That fixes things for me.
>
> --
> USB devices are not recognized when having ehci_hcd modprobed
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Can you find the hidden words?  Take a break and play Seekadoo!
http://club.live.com/seekadoo.aspx?icid=seek_wlmailtextlink

[sonst-was (sonst-was)]

uname -a:
Linux freddy-desktop 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux

[sonst-was (sonst-was)]

and here's the lspci-vvnn.log :

[Barteq (barteqpl)]

Same thing here, but according to Andrew Straw advice everything works fine.

Things went better after using 'echo Y > /sys/module/usbcore/parameters/old_scheme_first' but there were some extra usb resets and hdparm -t works extremly slow (showing 28 Mb/s but after some minutes of probing...). After doing 'echo -n -1 > /sys/module/usbcore/parameters/autosuspend' my external HDD works just fine!

My hardware is Acer 4283 based on Intel ich7 chip with Intel host controler.
HDD is 80 Gb toshiba momentus + external usb case.

With default Gutsy install with ehci_hcd loaded it looked like this

[...[
Sep 22 00:57:51 lap kernel: [10759.568000] Buffer I/O error on device sdc1, logical block 98309
Sep 22 00:57:51 lap kernel: [10759.568000] lost page write due to I/O error on sdc1
Sep 22 00:57:52 lap kernel: [10759.820000] usb 1-3: new high speed USB device using ehci_hcd and address 16
Sep 22 00:57:52 lap kernel: [10760.144000] scsi 27:0:0:0: rejecting I/O to dead device
[..]

After removing ehci module hdd just worekd but only at 900kB/s...

Turning off usb autosuspend with ehci_hcd loded coused external HDD works fine.

$ uname -a

Linux lap 2.6.22-11-generic #1 SMP Mon Sep 17 03:45:58 GMT 2007 i686 GNU/Linux

$ lsusb

Bus 001 Device 003: ID 058f:6390 Alcor Micro Corp.
Bus 001 Device 002: ID 046d:0896 Logitech, Inc.
Bus 001 Device 001: ID 0000:0000
Bus 005 Device 003: ID 046d:c517 Logitech, Inc.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000

$ lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce Go 7600] (rev a1)
04:00.0 Ethernet controller: Broadcom Corporation ...

[Brian Murray (brian-murray)]

usb autosuspend has been disabled in Gutsy's kernel as of 2.6.22-11.34 so this issue should be resolved as I understand it. Please report back if this in fact not resolved.

[midnightflash (midnightflash)]

~$ uname -r
2.6.22-12-generic

And the error still persists:

~$ tail -f /var/log/messages
Oct 6 16:51:11 ubuntu kernel: [ 5634.847550] usbcore: registered new interface driver usb-storage
Oct 6 16:51:11 ubuntu kernel: [ 5634.847703] USB Mass Storage support registered.
Oct 6 16:51:16 ubuntu kernel: [ 5639.840481] scsi 4:0:0:0: Direct-Access TOSHIBA MK4025GAS 0811 PQ: 0 ANSI: 0
Oct 6 16:51:16 ubuntu kernel: [ 5639.842528] sd 4:0:0:0: [sdd] 78140160 512-byte hardware sectors (40008 MB)
Oct 6 16:51:16 ubuntu kernel: [ 5639.844639] sd 4:0:0:0: [sdd] Test WP failed, assume Write Enabled
Oct 6 16:51:16 ubuntu kernel: [ 5639.845769] sd 4:0:0:0: [sdd] 78140160 512-byte hardware sectors (40008 MB)
Oct 6 16:51:16 ubuntu kernel: [ 5639.847499] sd 4:0:0:0: [sdd] Test WP failed, assume Write Enabled
Oct 6 16:51:16 ubuntu kernel: [ 5639.847506] sdd: sdd1
Oct 6 16:51:16 ubuntu kernel: [ 5639.862340] sd 4:0:0:0: [sdd] Attached SCSI disk
Oct 6 16:51:16 ubuntu kernel: [ 5639.862386] sd 4:0:0:0: Attached scsi generic sg3 type 0
Oct 6 16:53:16 ubuntu kernel: [ 5760.170184] usb 3-2: reset high speed USB device using ehci_hcd and address 5
Oct 6 16:53:51 ubuntu kernel: [ 5795.157411] usb 3-2: reset high speed USB device using ehci_hcd and address 5
Oct 6 16:54:50 ubuntu kernel: [ 5853.762545] usb 3-2: reset high speed USB device using ehci_hcd and address 5

[Alan Pope 🍺🐧🐱 🦄 (popey)]

I am also getting a USB key not recognised/mounted until I yank the ehci_hcd module under 2.6.22-13-generic on a Toshiba laptop..

[Solo0815 (triple-x)]

2.6.22-13-generic:
'sudo modprobe -r ehci_hcd' helped Kubuntu to recognize my USB-Hub ans USB-Stick.
PLS fix this Problem, thx in advance

[Markus Kienast (elias1884)]

One thing I want to add to the bug report which might be helpful is, that this used to work for me even in Feisty. I actually mentioned that earlier but it seems to have been overlooked. Updating to kernel 2.6.20-16-generic 2.6.20-16.29 did trigger the bug for me. My HP Photosmart C3180 used to work until after this kernel update. I can not tell for sure which version I was updating from, but it is a pretty good bet to examine all prior changes/patches to the USB subsystem.

By the way, my Mother just called me to state that USB stopped working altogether now. I had blacklisted the ehci_hcd module to downgrade to USB 1.0 but it seems this is broken now either. She mentioned she did perform a system update again, so this might have been introduced with the latest kernel update again, but as it is my Mothers laptop and I did not perform the update, I don't know. Just talked to her. Does not look like the kernel has been update.

Maybe we are all looking in the wrong direction. Maybe this is a udev problem.

Two other things I want to mention:

First, as you can see I am maintaining the Laptop of my Mother and also a couple of other machines, I do not have access to permanently. As nobody can expect people like my Mother to produce helpful bug reports, I am the one filing bug reports for all of them. I find it particularly hard to add hardware information like lshw output to the bug reports when I have no access to the machine. Therefore I proposed to add a feature to lauchpad to make it possible to add hardware information to launchpad user profiles. I could then refer to this information when writing bug reports. This would be especially useful, since I usually add the same stuff to more than one bug report anyhow. So why should I do the same again and again. I want to store this information in a central place.

Actually what I want is a tool that extracts that info and uploads it to a HWDB for me. Please have a look at bug #3382 if you find this interesting and please leave your comment if you are a user and want this feature to be implemented as well.

Secondly, as this bug concerns a good part of the Ubuntu userspace and well the need to downgrade to USB 1.0 to get your Printers, USB Pendrives, and the such is an embarrassment for Ubuntu, I think this bug also deserves to be tagged as "embarrassing". I don't mean this as an offense but want to emphasis how important it is to fix this. This is a NEEDS TO BE FIXED IMMEDIATELY bug simply because it affects lots of people and has the potential to scare away new users. It makes Ubuntu look "unpolished", "experimental", "unprofessional".

As mentioned in other places, I suggest to add a features to launchpad, that makes it easier for devs to track down these bugs of great importance to the userbase. I proposed a feature that allows users to rate the bugs "embarrassment" factor, just like you rate the quality of a video clip on youtube. Please see bug #149775 for details. The code could also be used for voting on wishlist items and blueprints.

Please forgive me that I added these two somewhat off-topic concerns here, but I believe they would be an important addition to the Ubuntu ecosystem.

[808y (808y)]

I can confirm this issue, if i start my usb2.0 i get the same errors like the others mentioned. i/o errors, reset usb device etc...
If i use modprobe -r ehci_hcd to unload it, and start than my hdd it just works fine, no issues at all, no messages or anything else(expect infos like its mounted) BUT with usb1.1 speed. Like the Bugreporter mentioned.

[808y (808y)]

€: My USB Controller, is a seperate pci card with VIA chipset. NOT a NForce board.

[808y (808y)]

my uname -a
Linux 2.6.22-14-generic #1 SMP Tue Oct 9 09:51:52 GMT 2007 i686 GNU/Linux

Oct 11 15:12:27 hermann-server kernel: [ 1215.996000] usb 3-1: device descriptor read/64, error -110
Oct 11 15:12:27 hermann-server kernel: [ 1216.212000] usb 3-1: new high speed USB device using ehci_hcd and address 5
Oct 11 15:12:32 hermann-server kernel: [ 1221.232000] usb 3-1: device descriptor read/8, error -110
Oct 11 15:12:37 hermann-server kernel: [ 1226.352000] usb 3-1: device descriptor read/8, error -110
Oct 11 15:12:38 hermann-server kernel: [ 1226.568000] usb 3-1: new high speed USB device using ehci_hcd and address 6
Oct 11 15:12:43 hermann-server kernel: [ 1231.588000] usb 3-1: device descriptor read/8, error -110
Oct 11 15:12:48 hermann-server kernel: [ 1236.708000] usb 3-1: device descriptor read/8, error -110

[808y (808y)]

after i did echo -n -1 > /sys/module/usbcore/parameters/autosuspend it was better, i got less messages if the kind
Oct 11 15:12:38 hermann-server kernel: [ 1226.568000] usb 3-1: new high speed USB device using ehci_hcd and address 6
Oct 11 15:12:43 hermann-server kernel: [ 1231.588000] usb 3-1: device descriptor read/8, error -110
Oct 11 15:12:48 hermann-server kernel: [ 1236.708000] usb 3-1: device descriptor read/8, error -110

but after coping 150MB the disc was "unsavely unmounted" :) , so it still exist for me even after
after i did echo -n -1 > /sys/module/usbcore/parameters/autosuspend .

a modprobe -r ehci_hcd is still the one and only thing what works for me, to ensure that my usb2.0 hdd works. But thats a problem 500GB with usb1.1 ...

[808y (808y)]

Additional Info:
When i use echo -n -1 > /sys/... paramters/autosuspend AND unloaded ehci with modprobe -r ehci_hcd i get the same errors as with
echo -n 2 > /sys/.. /parameters/autosuspend with ehci_hcd loaded, the only option that works for me is:

echo -n 2 > /sys/.../autosuspend and an unloaded ehci_hcd .

[808y (808y)]

lspci as sudo thistime, didnt the last time with sudo, so there were the capabilties missing, dont know if thats important.

[Germán Poo-Caamaño (gpoo)]

I had having the same issue using Gutsy, currently using 2.6.22-14-generic.

I would also to add, that all my USB 2.0 devices used to work until october 10.

I have tried the tips given here wthout success, except removing ehci_ucd, which is not an option for big external disks.

[Germán Poo-Caamaño (gpoo)]

Just to add some information, the USB controller is Intel:

00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)

[Stuart Vickers (sv87411)]

I have to agree with elias's comments on the 8/10/07 this is an embarrassing situation for Ubuntu. I, like so many others experience this problem and have been tracking this bug report for a long while; I mean, it has been going now for 8 months! I see little or no point in giving more information as nothing seems to being done to actually fix this problem and there's no structured mechanism to track the information provided in these bug reports; it's all pretty much just a bunch of random information.

I used to use external mass storage USB devices on my IBM laptop a lot under Windows with no issues. Those same devices on the same laptop produce the errors already reported in Ubuntu many many times above.

This one issue is giving Ubuntu and Linux in general bad press which is such a shame. This is definitely one situation where Windows and Microsoft have the upper hand.

[Markus Kienast (elias1884)]

I proposed some other more constructive feature than the "embarrassment"
rating tool before. Unfortunately it will never be implemented unless
Canonical or somebody else will fund the development.

While it is actually not that complicated to implement, it certainly
would be a great help for Ubuntu as much as for the Kernel developers
itself.

Bug #3382 - Should be able to attach hardware database id to bugs

It proposes to enable bug reporters to more easily submit hardware
information to bug reports. And giving the devs an easier way to query
which hardware is affected.

Step one: Add a GUI driven software to the Ubuntu distro which enables
users to submit their hardware information to a central database.

Step two: Allow the users to attach the DB IDs to their launchpad
profile (multiple if needed).

Step three: Allow the user to select which of his machines are affected.

Step four: Allow the bug fixers to retrieve a list of affected hardware
for a bug from launchpad. Like: give me all USB chipsets of machine IDs
attached to this bug.

This at least would give bug fixers a hint, where to start looking.

[John Zero (johnzero)]

The most annoying thing that this has worked in Edgy Eft. It broke in Feisty, then it's still broken in Gutsy.

My only 'workaround' was to either:
1. unplug the USB device from my USB hub and plug it directly into my machine, skipping the HUB. But I need the HUB because I have many USB devices
2. unload the ehci module (thereby losing USB 2.0 speed, back to good old slow USB 1.0/1.1)

[Markus Kienast (elias1884)]

On Thu, 2007-10-25 at 13:11 +0000, John Zero wrote:
> The most annoying thing that this has worked in Edgy Eft. It broke in
> Feisty, then it's still broken in Gutsy.
>
> My only 'workaround' was to either:
> 1. unplug the USB device from my USB hub and plug it directly into my machine, skipping the HUB. But I need the HUB because I have many USB devices
> 2. unload the ehci module (thereby losing USB 2.0 speed, back to good old slow USB 1.0/1.1)
>

As far as I can tell, it even worked in feisty for the longest while.
Just appeared or got worse after an update of some kind.

[Régis B. (regisb)]

This very same problem has happened to me for some time with KUbuntu Feisty and Gutsy. However, I just discovered that I do NOT have this problem when I use Gnome instead of KDE: USB keys are recognized and I can transfer at USB2.0 speed but only when I use Gnome.

Do the people who reported this problem use KDE or Gnome?

[Markus Kienast (elias1884)]

I use GNOME and have the Problem under Feisty.

On Mon, 2007-10-29 at 15:14 +0000, Régis B. wrote:
> This very same problem has happened to me for some time with KUbuntu
> Feisty and Gutsy. However, I just discovered that I do NOT have this
> problem when I use Gnome instead of KDE: USB keys are recognized and I
> can transfer at USB2.0 speed but only when I use Gnome.
>
> Do the people who reported this problem use KDE or Gnome?
>

[Alwin Garside (yogarine)]

Problem still persists for me in Gutsy. I connect my PSP and all seems well, I can even copy stuff from my PSP to the computer with 2.0 speed without any problem.

But when I try to copy a file to the PSP it starts to give I/O errors. Either while copying (in case of a large file) or while unmounting (if I copied a small file, and it was still in the write cache).

I attached my dmesg output:
[ 4302.993322] is the point where I started copying from the PC to my PSP.

[Harlan McCanne (hmccanne)]

I too see this problem in Gutsy on a DELL precision 360. Both my Sony camera and WD ext hard drive refuse to connect

Everything worked fine on Fedora 4. On Feisty and Gutsy, I need to rmmod ehci_hcd in order to mount either device.

changing autosuspend doesn't appear to help.

dmesg with ehci_hcd and autosuspend disabled is attached. The XEROX Phaser 6120 seems to work fine, although it does occasionally fail on jobs which could be an I/O type error as explained above, but it isn't common and I haven't had time to look at that

root@capri:/tmp# uname -a
Linux capri 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
root@capri:/tmp# lsusb
Bus 005 Device 004: ID 1058:0300 Western Digital Technologies, Inc.
Bus 005 Device 003: ID 0924:3d57 Xerox
Bus 005 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

and for the camera (a DSC-P100):

root@capri:/tmp# lsusb
Bus 005 Device 006: ID 054c:0010 Sony Corp. DSC-S30/S70/S75/F505V/F505/FD92 Cybershot/Mavica Digital Camera
Bus 005 Device 003: ID 0924:3d57 Xerox
Bus 005 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

[Alwin T. (alwint)]

Everything works fine for me now. I also had this problem since Feisty. I thougt I give it a try and here we go.
Just attached a USB-Hub and 2 Stick's and one scanner. And no more problmes. :-)
Attached is a small output from dmesg.

[Alwin T. (alwint)]

Everything works fine for me now. I also had this problem since Feisty. I thougt I give it a try and here we go.
Just attached a USB-Hub and 2 Stick's and one scanner. And no more problmes. :-)
Attached is a small output from dmesg.

[Markus Kienast (elias1884)]

Problem seems to be fixed for me too. One funny thing about it however
is, that ehci_hcd module has been loaded even though I had it
blacklisted.

[808y (808y)]

? I have an completly updated gusty, and it IS NOT FIXED for me!!!
Still have error's -72 and -110.

Dont know what you guys are talking about, but it isnt fixed for me, still same errors, still unsable ext. hdd with usb 2.0, only usable with usb1.1

[biffster (biffster)]

> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746

Well, I'll be damned, this has been fixed somewhere along the way in Gutsy.
Bravo to the team! It is so cool to be able to use my usb 2.0 card reader in
Ubuntu again.

--
Michael Fierro <email address hidden>
Y! Messenger: miguelito_fierro AIM: mfierro1
http://biffster.org http://weightjournal.com
--
Buzz: You are a sad, strange little man, and you have my pity. Farewell.

[Markus Kienast (elias1884)]

Yes, I find that particularly great as well.

Hope somebody soon fixes the flash video browser freeze bug. This is
another major annoyance.

[Søren Boll Overgaard (boll-fork)]

I am still seeing this bug as well, on a fully updated gutsy system.
Devices don't work when connected through a USB HUB.

[Alwin Garside (yogarine)]

@Martin:
You changed the status to "fix released"... However I haven't seen any relevant update so far, not even in gutsy-proposed. On my 64-bit system the bug still exists. (Still have to test it on 32-bit)

Was a fix actually released? I mean you aren't even a member of the kernel team, why did you change the status? Just because it 'Works For You'?

[808y (808y)]

i agree with the others, it needs as soon as possible, to re open, and marked as triaged(as it was ), i dont wanna sit here for years, because it was marked as fixed. It simply cant be called fixed when i cant use usb2.0 with an uptodate gusty.

[Alwin Garside (yogarine)]

So far not even a notice from the kernel team about what they _think_ the problem is. Also this bug is unrelated with autosuspend.

[Alwin T. (alwint)]

Don't know if that's important, but I made a clean install with Gutsy. I've only read here about updatet systems. So maybe some of you give Gutsy a try with a fresh install.

[Markus Kienast (elias1884)]

I have to revoke that I said earlier, the bug is fixed on my system.

It is not fixed.

However, I am seeing the bug only on some of my USB ports. I suspect
these ports are actually no native USB ports but internal HUB ports. I
will try to find out more. Still I am wondering, why it would not work
on a HUB port.

Accordingly, this bug needs to stay open.

[biffster (biffster)]

On Mon, Nov 05, 2007 at 09:00:13PM -0000, elias wrote:

> However, I am seeing the bug only on some of my USB ports. I suspect
> these ports are actually no native USB ports but internal HUB ports. I
> will try to find out more. Still I am wondering, why it would not work
> on a HUB port.

Interestingly enough, I am having success through a hub. I have a USB 2.0
connection between my computer and a USB 2.0 hub built into my Dell monitor.
I have a USB 2.0 multi-card reader plugged into the monitor. This
configuration did not work in Feisty nor the initial release of Gutsy. But
somewhere along the way, something changed, and everything works fine right
now.

--
Michael Fierro <email address hidden>
Y! Messenger: miguelito_fierro AIM: mfierro1
http://biffster.org http://weightjournal.com
--
"What do you think of my new face by the way? Hmmm? I wasn't to sure
of it myself to begin with, but it sort of grows on you."
- Doctor Who

[Markus Kienast (elias1884)]

Does Upstream ever read this bug tracker, or are all our comments
actually useless and we should rather report our problems to the kernel
bug tracker directly?

[midnightflash (midnightflash)]

What elias writes is exactly what I'm thinking for a long time now. I'm having the same Problem with Gentoo (gentoo-source-2.6.22-r8 genkernel) too. So it's per se an upstream problem... but is there (veritable) communication between them?

[Don (u-launchpad-piven-net)]

I've had success in working around the ehci-hcd error by recompiling the kernel WITH power management (CONFIG_PM=y) but WITHOUT ACPI support (CONFIG_ACPI not set). With this done, EHCI seems to be behaving... at the very least, it's not flooding my syslogs with "new high-speed USB device" messages and isn't squawking over a couple of large file transfers I'm doing right now.

That won't help those of you who depend on ACPI for power management, but...

(This is with kernel 2.6.23.1 under Gutsy.)

[Robert North (russetrob)]

With Ubuntu 7.10 (gutsy) I'm having some success.
NOTE: I have made no changes to the kernel at all.
I can successfully see all my devices.
In addition I have added a Cannon lpb5000 printer and and Epson perfection 3200 scanner, which are working correctly.

But.... I'm having minor problems with flash drives....
My USB flash drive will hang occasionally, and then reset. Transfers occur successfully, but slowly.
Doing the following in the root terminal cures the problem:
         echo -1 > /sys/module/usbcore/parameters/autosuspend
This is the suggested work-around for bug #85488, so I'll be adding further detatils there.
If anyone wants my current lsusb, lspci info, the will (soon) find that info in bug #85488.

[Robert North (russetrob)]

If you're still having trouble...
Looks like there are 2 things to try.....

1. Working without ACPI
       Q: would disabling acpi as kernel parameter suffice?
2. Disabling usb autosuspend.
       (See my last post for the method)

Q: What info do the developers to start repeating this bug, and fix it?

[Robert North (russetrob)]

Correction: *Everything* is working fine.

In my " Success with 7.10" comment applying the autosuspend off, and the flash drive working were a coincidence.
Further testing revealed that 9 times out of 10 the flash drive would pause and reset.

I have since switched to using a powered USB hub, and no longer get failures on the Flash device.
Obviously I will not be reporting anything in bug #85488.

So, here's my successful USB config:

[Pau Garcia Quiles (pgquiles)]

This bug has been fixed in Fedora and RHEL by reordering the modules. See bug 213411 in Red Hat's Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=213411

[Robert North (russetrob)]

Update on my last report.
It seems I may be experiencing intermittent failure of usb system on boot.
Will investigate when I have time.

[Tzadik Vanderhoof (tzadik-vanderhoof)]

Is there any way to automatically unload ehci_hcd on boot (or keep it from
loading in the first place).

On Dec 5, 2007 10:21 PM, Robert North <email address hidden> wrote:

> Update on my last report.
> It seems I may be experiencing intermittent failure of usb system on boot.
> Will investigate when I have time.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Tzadik

[Epíleg (epileg)]

En/na Tzadik Vanderhoof ha escrit:
> Is there any way to automatically unload ehci_hcd on boot (or keep it from
> loading in the first place).

add the line 'modprobe -r ehci_hcd' in file '/etc/rc.local', above 'exit 0'

[Markus Kienast (elias1884)]

Seagate snubs Linux
Latest drives show no visible means of support
http://www.theinquirer.net/gb/inquirer/news/2007/12/06/seagate-snubs-linux

What is reported in this article is most likely also caused by this bug. Maybe somebody starts to care!

[Robert North (russetrob)]

Ok, here's the kernel log from my current failing USB setup.
Not that this setup was previously succeeding.

[Robert North (russetrob)]

In previous e-mail second line should read:
Note that this setup was previously succeeding.

[Robert North (russetrob)]

And here's the lspci output to go with the kernel log.

[Markus Kienast (elias1884)]

Robert: On my Laptop, some ports are working and some do produce the
problem. I suspect this is due to some ports being native USB ports and
others being wired as internal USB hub ports.

You might want to check, if this is the case for your setup as well.

Some dev could go ahead and tell us, how we can determine, which ports
are direct native USB ports and which ones are internal hubs. There must
be a way to find that out, to verify my theory.

On Mon, 2007-12-10 at 02:36 +0000, Robert North wrote:
> Ok, here's the kernel log from my current failing USB setup.
> Not that this setup was previously succeeding.
>
> ** Attachment added: "Ubuntu 7.10 kernlog--usb errors"
> http://launchpadlibrarian.net/10819214/Ubuntu%207.10%20kernlog--usb%20errors
>

[Pär Lidén (par-liden)]

I've had the same problem, but just on my front ports. And I'm pretty sure it is because the wires are longer, and of lower quality, to the front ports. The back ports are connected directly to mainboard, via a riser. Usb 1.1 devices (such as mice and keyboards) work at the front ports, but not usb 2.0 devices (such as camera or memory sticks). If I unload usb-ehci it works.

So IMO, a solution to this could be some sort of fallback. If usb 2.0 doesn't work, try 1.1, and then notify the user. Win xp does this for my front ports. I don't know if this is hard to implement, I'm no kernel hacker. I was just about to post a feature request about this thing when I found this bug.

I have a ASUS P4C800 motherboard, with intel 875 chipset, and an Antec Sonata case (the original model). And I think the wires from the case are to blame in this case.

[Markus Kienast (elias1884)]

Pär:
This most certainly does not have anything to do with the length of the
cabling. But your front ports might be no native USB ports but internal
USB Hub ports. This however is just something I suspect to be the reason
for the bug. However, unless some developer has a look at that or at
least advises me, how to verify my theory, this will just stay
speculation.

On Mon, 2007-12-10 at 12:08 +0000, Pär Lidén wrote:
> I've had the same problem, but just on my front ports. And I'm pretty
> sure it is because the wires are longer, and of lower quality, to the
> front ports. The back ports are connected directly to mainboard, via a
> riser. Usb 1.1 devices (such as mice and keyboards) work at the front
> ports, but not usb 2.0 devices (such as camera or memory sticks). If I
> unload usb-ehci it works.
>
> So IMO, a solution to this could be some sort of fallback. If usb 2.0
> doesn't work, try 1.1, and then notify the user. Win xp does this for my
> front ports. I don't know if this is hard to implement, I'm no kernel
> hacker. I was just about to post a feature request about this thing when
> I found this bug.
>
> I have a ASUS P4C800 motherboard, with intel 875 chipset, and an Antec
> Sonata case (the original model). And I think the wires from the case
> are to blame in this case.
>

[Markus Kienast (elias1884)]

Has this bug been reported upstream? I am always wondering how Ubuntu's relationship with upstream is? This bug is around for about a year now, and it does not look to me, as if anybody - at least from upstream - has even had a look at it.

Please also advise if there is even a facility to escalate this bug upstream or if it would be better, we reported these kernel specific bugs upstream ourselves!

[Markus Kienast (elias1884)]

To: <email address hidden>

I would need a way to determine which of my USB ports are actual native
ports and which are internal USB hub ports. How can I achieve that
easily?

The reason being is, that I want to investigate a theory to this bug:

---
Certain USB devices do not work properly, or do not work at all, while
the ehci_hcd module is loaded.

A solution is to unload the ehci_hcd module, which is loaded every time
the computer starts, using the command 'sudo modprobe -r ehci_hcd'. This
works fine but unfortunatly ehci-hcd is necessary for using USB 2.0, so
you lose USB 2.0 features.

Get more info at https://bugs.launchpad.net/bugs/88746
---

This bug is bugging me for about a year now. However, this bug is not
showing up on all my USB ports. As this problem has be reported to show
up particularly on USB Hubs, I suspect it might only show up on those of
my USB ports that are actually internal USB Hub ports. I would like to
verify that theory but would need advice on how to do that.

Maybe somebody could also have a look at the bug report mentioned. This
bug has been reported beginning of this year in the Ubuntu bug tracker.
Up till now, it does not seem like anybody has laid hand on it yet.

I also have no idea if this bug report even made it upstream. Does
Ubuntu/Launchpad have a facility to escalate bugs to the kernel bug
tracker? I am somehow loosing faith in the whole Launchpad approach.
Maybe you could advise if I should rather report kernel specific bugs
directly to the kernel bug tracker instead of hoping the Ubuntu guys
will take care of channeling it upstream.

Elias

[midnightflash (midnightflash)]

There are several reports about this bug to find in http://bugzilla.kernel.org. FE:
http://bugzilla.kernel.org/show_bug.cgi?id=5835
http://bugzilla.kernel.org/show_bug.cgi?id=6194
http://bugzilla.kernel.org/show_bug.cgi?id=8023
http://bugzilla.kernel.org/show_bug.cgi?id=6374 ...

Surly there are more to find... :-/

[nusigmaforce (doctorcelebro)]

I just can't wait to get this fixed!

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Tue, 11 Dec 2007 18:12:03 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> There are several reports about this bug to find in http://bugzilla.kernel.org. FE:
> http://bugzilla.kernel.org/show_bug.cgi?id=5835
> http://bugzilla.kernel.org/show_bug.cgi?id=6194
> http://bugzilla.kernel.org/show_bug.cgi?id=8023
> http://bugzilla.kernel.org/show_bug.cgi?id=6374 ...
>
> Surly there are more to find... :-/
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
The best games are on Xbox 360. Click here for a special offer on an Xbox 360 Console.
http://www.xbox.com/en-US/hardware/wheretobuy/

[iMaNeX (imanex)]

I have the same problem in ununtu gutsy, I have the nvidia2 chipset also. Is there no fix to this problem? I really need usb2.0 to use linux, im thinkin of going back to windows or giving suse a whirl. I never had this problem in earlier versions of ubuntu. When I terminate 'ehci_hcd' things start to work at a crawling pase, everything detects and I cant upload anything to the card reader or external hard disk. Please if anyone knows a remedy for this other than throwing 'modprobe -r' in the boot, let me know.

Ive attached the requested logs of dmesg etc to assist the people working on this problem. Is it possible to like downgrade your kernel without ubuntu cracking the shits? Or is ubuntu like coded for the kernel or something... (Linux N00b Here!)

Thanks,
-iMaNeX

[iMaNeX (imanex)]

My dmesg.log file...

[iMaNeX (imanex)]

My lspci.log file...

[iMaNeX (imanex)]

My lsusb.log file...

[Pär Lidén (par-liden)]

Elias:
Maybe it's not because of the length of the cables, but then the quality of them, in my case (case as in situation, not box). I bought the parts in 2003, and probably the case model is older than that. Maybe usb 2.0 was too new then for them to test it properly. Maybe my problem is a bit different than the others here. In Winxp I'm able to use the devices, but just at 1.1 speeds. That is why i suspect the cabling and not the os in my case. And a similar feature as in winxp would be very nice in my case.

I've built the computer myself, and know exactly what's in there. The front ports are connected with wires straight to the pins at the motherboard, so that's not what I would call a hub. But it doesn't work anyway. The ports which does work are the ports directly from the motherboard (no wires), at the back fo the of the case. However, I'm not sure exactly what defines a hub. I place one 10-pin connector to the motherboard, but has two usb-ports at the front. Maybe there is a hub then? So maybe my case would support your theory.

[Markus Kienast (elias1884)]

Pär:
My setup used to work. Then stopped working. With the same external
cables. And one port always works, two others don't. I doubt, that there
is a problem with the internal cabling quality, if there even is any.
And if there is, the cables are to short that quality would matter.
Anyhow, I have full USB 2.0 on all ports in WinXP.

I have to try another kernel and see what happens then. I myself do not
have any idea what qualifies as HUB and what is a native port either.
Have to read up on that. So far my theory is just speculation.

Elias

[Sergio Callegari (callegar)]

I confirm the issue.

To me it is happening with a PCMCIA UMTS card where the card implements the modem as a USB device that gets attached to the PC by a USB interface provided by the card itself.

The thing works without ehci_hcd and does not with it.

With ehci_hcd I do not even see the device from the very start.

Sergio

[Henrik Nilsen Omma (henrik)]

Could you please test this with Hardy (2.6.24 kernel)? Thanks!

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Testing with Ubuntu Hardy Alpha 1 live environment.. Insert the USB key, nothing happens, yank the ehci_hcd module and the system detects and mounts the USB key.

[Robert North (russetrob)]

I've got my system working after doing the following:

root@rob-desktop:~# modprobe -r ehci-hcd
root@rob-desktop:~# echo -n -1 > /sys/module/usbcore/parameters/autosuspend
root@rob-desktop:~# modprobe ehci-hcd

Everything now seems to be working.
From past experience, I'll keep testing, because this may change :-(

[Robert North (russetrob)]

Ok, and here's the kernel log for the above session.
Note that the system start wth failing ehci.
At around 14:11:10 I execute the commands above, and everything seems to start working.

[Robert North (russetrob)]

I think everyone using Gutsy should try the autosuspend workaround, and report on bug# 85488 as directed here:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/102

NOTE: I could only get this working by removing ehci, and re-installing.
Simply setting the autosuspend wasn't sufficient.

[Henrik Nilsen Omma (henrik)]

Closing the Gutsy task and approving the Hardy target nomination.

[Leann Ogasawara (leannogasawara)]

Hi Robert,

Thanks for testing with the Hardy Alpha1 LiveCD. Unfortunately, Alpha1 was released with the previous 2.6.22-14 kernel from Gutsy. This should not be the case for Alpha2 which is set to come out around Dec 20th. Care to retest once Alpha2 comes out? I'll be sure to update this report when it is available. Thanks!

[Robert North (russetrob)]

Leann, I tested with Gutsy not Hardy.

I would have tested with Hardy but couldn't find the live cd.
...When Alpha2 comes out, where will I find the live CD?

[Robert North (russetrob)]

Another thing to note is that my devices were working with Gutsy....
And then mysteriously stopped working.
Maybe a kernel update caused this?
I believe Elias also reported this above.

[John Zero (johnzero)]

Yesterday I accidentally booted with kernel 2.6.17 (I think from Dapper?) and everything worked totally perfectly!
ehci_hcd was loaded, running, everything was fine, USB was working at the fast, 2.0 speed.

[Tzadik Vanderhoof (tzadik-vanderhoof)]

On Dec 18, 2007 4:39 AM, John Zero <email address hidden> wrote:

> Yesterday I accidentally booted with kernel 2.6.17 (I think from Dapper?)
> and everything worked totally perfectly!
> ehci_hcd was loaded, running, everything was fine, USB was working at the
> fast, 2.0 speed.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I also have no problem with Dapper.

[Markus Kienast (elias1884)]

Canonical:
Please attend to bug #3382! This would make bug tracking so much easier!

Everybody else:
Everybody who is bored of uploading dmesg, lshw, lspci, lsusb outputs repeatedly to the numerous bugs they are reporting, please check out bug #3382 and leave your comment there, to give it more weight!

[Markus Kienast (elias1884)]

Canonical/Ubuntu:
I am sure you all have realized by now, that you have a bug tracking/fixing problem. If I look at the numerous bugs I have reported and the few that have been marked fixed, that draws a pretty clear picture. The reason being in my opinion is, that many bug reports do not get the proper HW info to track down what is exactly going on. Many bugs actually are two or more bugs, which are hard to separate as long as the proper HW info has not been submitted.

For those of us who report many bugs, having to do the same things over and over again, is really painful and in the long term will stop us from reporting. Why can't we get a tool to simply upload out HW profiles to our launchpad profiles, so we can simply refer to that information instead of uploading the same stuff over and over again?

Isn't that the purpose of software, to do for us those tasks which are the same every time anyway?

Check out bug #3382 and pay somebody to get this implemented.

[Charles_R (charles33listes)]

Hello everybody.

Did some of you read this ? :
http://www.thinkwiki.org/wiki/Problem_with_USB_2.0
"Symptoms include inability to connect to USB 2.0 devices at USB 2.0 speeds, the "This device can perform faster" pop-up in Windows XP, device ID assignment error messages from the Linux kernel, and frequent reboots of the USB bus and connected devices."

On T40, T41 computers, the same problem occurs, even with Win XP. Some even suggesting to try with linux before flashing bios !...
It looks highly possible that the real origin is a defective southbridge controler, probably a model used with many motherboards.
I observed a curious randomly behaviour in the defect, believing that what I tried the day before to solve the problem had some effect before it happens again. This looks like an electronic problem, probably something to do with high speed of signals with USB2.0 standard. When you come back to USB 1, it works.
If some older kernels are using different codes to access USB 2.0, they also could help...
Anyway this bug is a real mess for me too

[NoWhereMan (e.vacchi) (uncommonnonsense)]

On Dec 24, 2007 1:33 AM, Charles_R <email address hidden> wrote:
> Hello everybody.
>
> Did some of you read this ? :
> http://www.thinkwiki.org/wiki/Problem_with_USB_2.0
> "Symptoms include inability to connect to USB 2.0 devices at USB 2.0 speeds, the "This device can perform faster" pop-up in Windows XP, device ID assignment error messages from the Linux kernel, and frequent reboots of the USB bus and connected devices."
>

oh! finally something that doesn't work *both* under win and linux :D
it's encouraging :D

[Leann Ogasawara (leannogasawara)]

Just an FYI for anyone interested. . . Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!

[nusigmaforce (doctorcelebro)]

Thanks Leann. I tried Alpha 1, but I will take a look at Alpha 2.

Axel Ramirez
The World's Best-Engineered PCs.Lenovo: New World, New Thinking. http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

----------------------------------------
> From: <email address hidden>
> To: <email address hidden>
> Date: Fri, 28 Dec 2007 03:10:42 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> Just an FYI for anyone interested. . . Hardy Heron Alpha2 was recently
> released. It contains an updated version of the kernel. You can
> download and try the new Hardy Heron Alpha2 release from
> http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able
> to then test the new kernel via the LiveCD. General information
> regarding the release can also be found here:
> http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!
>
> ** Changed in: linux (Ubuntu Hardy)
> Status: Triaged => Incomplete
>
> ** Tags removed: hardy-alpha2
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
i’m is proud to present Cause Effect, a series about real people making a difference.
http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect

[Pär Lidén (par-liden)]

FYI: I've filed a wishlist bug about automatic fallback to usb 1.1 if 2.0 doesn't work. In that way you won't manually have to unload ehci-hcd, so it could be some sort of workaround for your problem here (at least for most of you) You can look at https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/177430 if you're interested.

It worked equally bad for me with Hardy alpha2, but as I said I think my problem is bad internal cabling.

[John Zero (johnzero)]

@Pär Lidén:
I think falling back to USB 1.1 if 2.0 is not bad, but it's not grabbing the problem.

Let's repeat:
Same hardware setup in both tests:
- Booting Gutsy with the (old) 2.6.17 kernel: USB 2.0 works and speed is fast, perfect
- Booting Gutsy with the included 2.6.20 kernel: USB 2.0 doesn't work, removing ehci is a workaround, speed is slow

There is no hardware issue. Hardware is totally the same. It's probably the driver that has changed. Maybe the hardware was not 100% compliant but 2.6.17 driver handled this well, don't know.

[Markus Kienast (elias1884)]

Falling back to USB 1.1 totally misses the point!

If you want to fall back to something than fall back to autosuspend=0!!!

That is the fix, not removing the ehci_hcd module!

I have recently tired the "disabling autosuspend" workaround on my
mothers laptop and now all ports work again!

[Markus Kienast (elias1884)]

Autosuspend might be a great feature, but as long as it is not working
on all systems, I suggest to disable it all together in Hardy, which is
supposed to be a stable release!

[Charles_R (charles33listes)]

Some say
"There is no hardware issue. Hardware is totally the same." (Pär Liden). But according to the FACT that machines with XP have the SAME problem shows that "there is no kernel issue" ... !
How can you explain this ? My point of view is that SOME kernel version are not compatible with SOME southbridges. So that either changing kernel or motherboard would solve the problem.

To Elias Humbolt : in what file have you to set autosuspend=0 ?

[Robert North (russetrob)]

Charles:
I gave the commands to test disabling autosuspend above.....
Details are in the following comment....
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/188
*Note* you must be logged on as root at the console to do this.

Please try it, and report back.

I believe there are comments that provide suggestions of how to apply this work-around permanently, which I'm about to search for.

[Robert North (russetrob)]

I've now tried putting the autosuspend into the boot procedure....
After power-on this works succesfully.
There may still be problems after a restart.

My procedure was as follows:

1. Type the following in a terminal window:
         sudo gedit /etc/modprobe.d/usb-core-options
2. Add the following line to the usb-core-options file:
        options usbcore autosuspend=-1
3. Save your changes, and then type the following in a terminal window:
      sudo update-initramfs -u
4. Shutdown and power on your computer. (Don't use the restart option)

[Robert North (russetrob)]

Update to last report:
My problems on restart are not related to this bug.
But I definitely need a full restart before everything is working fully.

[Robert North (russetrob)]

I have just tried the Hardy alpha2 live CD, and still get this problem.
Changing the autosuspend option at the command line doesn't work.

I would like to try changing this in the Hardy live CD initframfs, but don't know how.
Any ideas?

[Robert North (russetrob)]

The following link contains important documentation for users & developers regarding this bug....
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/usb/power-management.txt;h=b2fc4d4a99177be7bd48dce560d1f28417c60aa9;hb=HEAD

This decsribes issues in the 2.6.24 kernel....
In short, so many USB devices don't autosuspend properly, that blacklisting them has been pushed to user-mode.
By default in the new kernel, autosuspend is disabled for everything but USB hubs.
Because they've left autosuspend enabled for USB hubs, and this may still be hitting some of us.
(Maybe that's what I've been seeing when running Hardy alpha2)

[Markus Kienast (elias1884)]

Robert North:

Actually my USB ports are reporting as internal USB HUB ports in dmesg.
And these internal USB HUB ports don't seem to work with autosuspend! I
can only repeat what I said earlier: Screw it! Turn of autosuspend
completely in Hardy as long as it is causing on any system!!!!!!

It does not make no sense to look unpolished just for the few gains a
minority of people has from that feature. Anybody who wants to conserve
power will just unplug USB devices he is not using anyways!!!!

If you still want to go on fixing this with blacklists ...., you can
check which chipset I have in the many hardware information I have
submitted already. I know it sucks, that you have to walk your way
through this bug report to find the right bits and pieces and that is
why I can't stop to rally for this bug/wishlist item: Bug #3382

It describes how HW information should be attached to ones launchpad
profile, so one would not have to upload the same stuff to so many
different bug reports over and over again.

It also describes how the HW info could be gathered by a/the HWDB tool.

And it describes how convenient it could be for devs/bugfixers to e.g.
query for a list of all USB chipsets affected by this bug.

Without that, I can't imagine tracking down HW bugs can be any fun!

On Sun, 2007-12-30 at 01:49 +0000, Robert North wrote:
> The following link contains important documentation for users & developers regarding this bug....
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/usb/power-management.txt;h=b2fc4d4a99177be7bd48dce560d1f28417c60aa9;hb=HEAD
>
> This decsribes issues in the 2.6.24 kernel....
> In short, so many USB devices don't autosuspend properly, that blacklisting them has been pushed to user-mode.
> By default in the new kernel, autosuspend is disabled for everything but USB hubs.
> Because they've left autosuspend enabled for USB hubs, and this may still be hitting some of us.
> (Maybe that's what I've been seeing when running Hardy alpha2)
>

[NoWhereMan (e.vacchi) (uncommonnonsense)]

I do second that. HW must be "just works", not "almost works" or
"sometimes works", or, worse, "why the hell isn't working??"

On Dec 30, 2007 11:05 AM, Elias Humbolt <email address hidden> wrote:
> Robert North:
>
> Actually my USB ports are reporting as internal USB HUB ports in dmesg.
> And these internal USB HUB ports don't seem to work with autosuspend! I
> can only repeat what I said earlier: Screw it! Turn of autosuspend
> completely in Hardy as long as it is causing on any system!!!!!!
>
> It does not make no sense to look unpolished just for the few gains a
> minority of people has from that feature. Anybody who wants to conserve
> power will just unplug USB devices he is not using anyways!!!!

[nusigmaforce (doctorcelebro)]

Ubuntu Hardy Alpha 2 has the same problem. When installing Hardy, it saw (other than the internal WD HDD) the USB Maxtor OneTouch II HDD as an option. So it sees the external USB HDD, but it doesn't displays it on the Desktop or anywhere else.

Axel Ramirez
The World's Best-Engineered PCs.Lenovo: New World, New Thinking. http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

----------------------------------------
> From: <email address hidden>
> To: <email address hidden>
> Date: Sun, 30 Dec 2007 19:26:26 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> ** Changed in: linux (Ubuntu Hardy)
> Status: Incomplete => Triaged
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Don't get caught with egg on your face. Play Chicktionary!
http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec

[Robert North (russetrob)]

Well, I have to agree with Elias and NoWhereMan.
USB autosuspend needs to be disabled in Hardy.

Probably best to do it by config in the initrd so that brave users can modify it without a re-compile.

(I've looked into the git repository for ubuntu.... and if I'm looking at the correct stuff, then USB works exactly like a vanilla 2.6.24 kernel.
This means that *if* autosuspend is the problem it *is* a problem with these hubs... hence my concusion)

P.S. Before anyone asks.... I am a clueless Ubuntu user *not* an Ubuntu developer.

[archdrone (archdrone)]

I have the same problem on old VIA chipset, MSI mainboard 6380 (lspci attached). (Plug USB 2.0 stick in, dmesg->error -71 or -101 etc, but when ehci_hcd rmmodded everything works)
It's weird that when I unplug the system disk and use it in nForce4 chipset, 2-year-old Gigabyte mainboard (can't show specs now) so that I have exactly the same Ubuntu on the other PC, the problem is gone or more precisely I've never seen this problem on the newer PC.

Ubuntu 2.6.24-2.4-generic
Linux ab-desktop 2.6.24-2-generic #1 SMP Thu Dec 20 17:36:12 GMT 2007 i686 GNU/Linux

[Eivind Ødegård (eivind)]

This may be unrelated, but still...

2.6.22-14-generic on a laptop running Gutsy mounts usb flash drives perfectly.
2.6.22-14-rt does not.

I can give additional information if needed and if guided.

[Francesco Potortì (pot)]

After upgrading to Gutsy, using 2.6.22-14-generic, the problem disappeared.

However, I see that ehci_hcd is not loaded any more, and I do not know why. So I tested the speed of my new 2GB USB 2.0 memory stick. This is what I did as root:

sync; sleep 5; start=$SECONDS; dd if=/dev/zero of=/media/BOMBO/zero-noehci bs=1M count=119; umount /media/BOMBO/; echo $((1000000/(SECONDS-start))) kb/s

and I got 8333 kb/s without ehci_hcd. Then I loaded the ehci_hcd module and reinserted the USB stick, which was recognised and automounted. I did the above test again and I got exactly the same results. This is a 5 year old box, so maybe its USB speed cannot be higher than the number I measured, which is 1 MB/s. However, if it is true that ehci_hcd is necessary for USB 2, then I do not know why it is not loaded in the first place.

[Markus Kienast (elias1884)]

@Francesco Potortì
maybe your ports are usb 1.1 not 2.0.

[Francesco Potortì (pot)]

>@Francesco Potortì
>maybe your ports are usb 1.1 not 2.0.

I will check, but anyway before upgrading to Gutsy I had this problem,
which I had solved by removing ehci_hcd. Now ehci_hcd seems to have no
influence any more, because the behaviour is the same when it loaded or
not.

The strange thing is that it was loaded by default with Feisty, now it
is loaded no more with Gutsy. I made the checks by loading it manually.

[Alwin Garside (yogarine)]

I just want to remind people that:

1.) For many people the autosuspend fix doesn't resolve this bug (for me it didn't)
2.) This bug may also be caused by low quality cables. For example, a low quality 1.1 cable will give I/O errors when connecting a USB 2.0 device with it.

Actually, I think that quite a lot of cases of this bug are caused by low quality cables and/or wiring.
So if you notice that you experience this problem in both Windows and Linux, please check if your USB cables are _real_ USB 2.0 cables. Also, if you're using the cases front plugs, try the plugs in the back. Chance is the wiring inside your PC case is of low quality.

So a fallback to uhci_hcd would resolve point 2, and temporarily fix 1 while it still isn't solved. Fixing this bug _soon_ is more important than fixing it _ the proper way_. Most Normal People care more about the fact that their device works than transfer speed.

[Robert North (russetrob)]

Still failing in hardy a4.

[Robert North (russetrob)]

A fall back to 1.1 speeds when ehci fails sounds good.
Probably should warn users when this is happening, if in desktop mode, via dialog, or notification in toolbar.

[Robert North (russetrob)]

I have just had a look through the lspci logs attached to this bug and a significant number are nvidia nforce2 motherboards.

So, can I ask all users with nforce2 to try my auto suspend suggestion.
       (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209)
NOTE: Once you've done this, be sure to *power down* before trying to re-boot, as on a re-start the USB hardware is still confused.

(P.S. Arwin's board is not an nvidia)

[Francesco Potortì (pot)]

>>maybe your ports are usb 1.1 not 2.0.

It may well be. I bought that motherboard in December 2001, and its
booklet just mentions "USB" without any version number. The rest of my
previous observations still hold.

[Markus Kienast (elias1884)]

There is a simple solution to all these problems. Unfortunately
Ubuntu/Canonical Devs don't seem to find it appealing.

As mentioned above turning off USB autosuspend all together solves the
problems most people encounter. It's just Ubuntu/Canonical seem to
prefer having this enabled for the sake of being able to tell "we are
concerving energy" while sacrificing USB 2.0 speeds for most of us!

I am fully supporting conserving energy measures, but they need to work
100% reliable for everybody. At least in an LTS release!

You guys can turn it on again after Hardy! But let things work out of
the box for everybody in Hardy LTS!!!

Elias

[Ben Collins (ben-collins)]

Elias, you are over simplifying this issue. If we disable autosuspend, then suspend/resume wont work for a good portion of people. After long ago weighing the options, we had to decide on the lesser of two evils: suspend/resume working for a large group of users, or usb2.0 working for an equally large group of users. Considering that both problems have work arounds, the decision was made based on expected behavior. Usually a system with usb2.0 ports that were affected by the problem also had usb1.0-only ports that did work. So users could continue to use their devices without much problem (although at a slower speed).

Also, please don't exaggerate how many people are affected by this. Over all, it's a small percentage of people. I have > 15 laptops, covering a large range of chipsets, and none of them are affected by either problem.

[nusigmaforce (doctorcelebro)]

Ben,
I have many computers (all IBM/Lenovo) as well and my 300GB Maxtor OneTouch II USB hard drive used to work perfectly in Edgy for both laptops and desktops (using USB 1.0 or 2.0). Gusty somehow introduced the problem, and the problem is still on Hardy as far as I can tell.

At some point it worked (in Edgy) and using the same hardware with Gusty/Hardy introduced the problem. So the question is, was the autosuspend introduced in Gusty what broke it or was it something else? If it was the autosuspend, yes we have workaround but, how about getting USB 2.0 and autosuspend to work at the same time. If it was not the autosuspend, then we would like more debug done to see where's the conflict in the echi_hcd module and hopefully get it fixed.

I also tried gOS and Linux Mint, but because they are based on Ubuntu Gusty they have the same issue. I wonder if the Maxtor USB drives were tested in Debian and therefore Gusty/Hardy.

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Mon, 4 Feb 2008 21:13:19 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> Elias, you are over simplifying this issue. If we disable autosuspend,
> then suspend/resume wont work for a good portion of people. After long
> ago weighing the options, we had to decide on the lesser of two evils:
> suspend/resume working for a large group of users, or usb2.0 working for
> an equally large group of users. Considering that both problems have
> work arounds, the decision was made based on expected behavior. Usually
> a system with usb2.0 ports that were affected by the problem also had
> usb1.0-only ports that did work. So users could continue to use their
> devices without much problem (although at a slower speed).
>
> Also, please don't exaggerate how many people are affected by this. Over
> all, it's a small percentage of people. I have > 15 laptops, covering a
> large range of chipsets, and none of them are affected by either
> problem.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx

[Francesco Potortì (pot)]

>At some point it worked (in Edgy) and using the same hardware with
>Gusty/Hardy introduced the problem. So the question is, was the
>autosuspend introduced in Gusty what broke it or was it something else?

No, it was before Gutsy. To me, it happened after some upgrade in Edgy.

>If it was the autosuspend, yes we have workaround but, how about getting
>USB 2.0 and autosuspend to work at the same time. If it was not the
>autosuspend, then we would like more debug done to see where's the
>conflict in the echi_hcd module and hopefully get it fixed.

My motherboard has most probably USB 1 ports. When I had the problem in
Edgy, I had to remove the ehci_hcd module to solve it. Now with Gutsy
ehci_hcd is not loaded any more, and everything works. Even If I load
ehci_hcd by hand everything keeps working.

[biffster (biffster)]

On Monday 04 February 2008 02:13:19 pm Ben Collins wrote:

> Elias, you are over simplifying this issue. If we disable autosuspend,
> then suspend/resume wont work for a good portion of people. After long

I don't know about others, but I would much rather have USB 2.0 working than
suspend/resume. While suspend/resume is kinda cool, USB 2.0 is a necessity.
There's a reason I buy USB 2.0 devices: USB 1.1 is simply far too slow. I
need USB 2.0 to work. If that breaks suspend/resume, so be it.

USB is a standard part of most user's computing experience. Suspend/resume is
something that only a small number of users will use. I think it would be
much more logical to put Suspend/Resume as an OPTION, not as a the default
configuration.

--
Michael Fierro <email address hidden>
Y! Messenger: miguelito_fierro AIM: mfierro1
http://biffster.org http://weightjournal.com
--
Giggywig: That's what they want us to think. Let me tell you something: one
 false move and kaboom! You'll be going home in several more pieces than
you arrived.

[Oisín Mac Fhearaí (denpashogai)]

On 06/02/2008, biffster <email address hidden> wrote:
>
> On Monday 04 February 2008 02:13:19 pm Ben Collins wrote:
>
> > Elias, you are over simplifying this issue. If we disable autosuspend,
> > then suspend/resume wont work for a good portion of people. After long
>
> I don't know about others, but I would much rather have USB 2.0 working
> than
> suspend/resume. While suspend/resume is kinda cool, USB 2.0 is a
> necessity.
> There's a reason I buy USB 2.0 devices: USB 1.1 is simply far too slow. I
> need USB 2.0 to work. If that breaks suspend/resume, so be it.
>
> USB is a standard part of most user's computing experience. Suspend/resume
> is
> something that only a small number of users will use. I think it would be
> much more logical to put Suspend/Resume as an OPTION, not as a the default
> configuration.

I don't agree at all. USB 2 is just an faster version of USB 1.1. Suspend
and resume either works or doesn't work. I can tolerate less USB bandwidth
if it's necessary to have suspend and resume working. You still have
_working_ USB, and I still have my suspend capability, which I use all the
time (because it means I can leave my machine for 30 minutes or hours or
weeks, without having to shut everything down and start up again next time).

Oisín

[archdrone (archdrone)]

External HDD using USB 1.1 is practically useless. Similarly for digital cameras, mp3 players, scanners, etc. Noone wants to wait hours for their music to get to the player on ubuntu especially when everything is OK on windows. Both USB 2.0 and suspend&resume are essential these days for ubuntu.

[brim4brim (maherb)]

Hi,

Pardon my ignorance but I posted in one of these bug threads ages ago and have been getting the updates ever since and reading them to see how the issue is coming along.

My ignorant question is:

If disabling auto suspend fixes the problem then is there a way to script it so when a transfer is starting (or when a USB 2.0 device is plugged in), autosuspend is disabled and then have it reloaded when the devices are ejected (or unplugged or inactive for a period of time).

The reason I ask is I don't believe any user is going to want to autosuspend while transferring files or working with a USB 2.0 device. It could probably be declared a feature to prevent users from accidentally entering auto suspend mid transfer.

[Francesco Potortì (pot)]

>I don't agree at all. USB 2 is just an faster version of USB 1.1.

No. There are some fairly common cases where USB 1.1 just won't do.
External disks are one example, videocameras are another. And anyone
doing regular big backups on a memory stick are yet one more. In these
cases, not having USB 2 just means that you cannot do the job.

> Suspend
>and resume either works or doesn't work. I can tolerate less USB bandwidth
>if it's necessary to have suspend and resume working. You still have
>_working_ USB, and I still have my suspend capability, which I use all the
>time (because it means I can leave my machine for 30 minutes or hours or
>weeks, without having to shut everything down and start up again next time).

This makes it clear that for some (not negligibly small) classes of
users USB 2 is a must, and for some other ones, suspend is a must. It
could be that the intersection of the two is not negligible either.
Anyway, if one is obliged to choose whether USB 2 or suspend should
work, then better letting the user choose.

[kainalu (kainalu-mcs)]

same prob here on gutsy get similar output on dmesg and such

[Markus Kienast (elias1884)]

@Ben Collins

Ben, I am happy that somebody from Ubuntu is finally reacting to this
Bug report. If not for fixing it than at least with an official
statement what devs are actually thinking about the issue. And why
obvious simple measures are not taken.

Your argumentations surely is not bare any logic. My first reaction
however was, well if suspend/resume is ought to be broken after
removing/disabling the autosuspend feature, why can I still successfully
suspend/resume on my laptop after disabling it. So now I have both, USB
2.0 and suspend/resume. You understand that some doubts did arise in me
about your claim removal of autosuspend might screw up suspend/resume
for many people.

However, these doubts do not have many grounds just yet, except for my
single perception on one type of system. Therefore I presume what you
are claiming are well tested facts.

I am wondering however, if it would not be possible to enable
autosuspend for the one crowd of chipsets while disabling it for the
other. Sure, not an easy task to identify, which systems to enable and
which not.

Extracting all this information from bug reports surly is hell. And yet,
if you have talked everybody into submitting their data "again", you
still will have to ask all of them to test whether or not disabling
autosuspend breaks suspend/resume for them. This is a challenge for
itslef. Undoable if you ask me, at least with the tools available.

I therefore understand, why literally nothing is done about it!

Undoable, well not if Launchpad had the proper toolset for this! I
actually proposed a feature which would enable you to handle a task like
that: The "attach HW profiles to launchpad accounts" I proposed a while
ago. https://bugs.launchpad.net/bugs/3382

I just had a couple of more ideas on how else this feature could be used
with a little more code.

Oh man, somebody needs to implement that! Have a look. I am happy to
share the idea, but I wont code for free on a proprietary project. And
well, the idea was mine, so don't start crying if RedHat or anybody else
is copying it. This idea is a free for all still!

Imagine how much better bug tracking would work if you could start a
simple poll:
Does disabling autosuspend fix your USB2.0 problem ? yes/no
Does disabling autosuspend break your suspend/hibernate/resume? yes/no

If more than one HW profile is registered with your launchpad account
the following question shows up:
Select the systems these answers apply to ? Choose form list.

And at the end you would know not just for how may people disabling
autosuspend works ... but also what chipsets are affected!

Wouldn't that be coding hours wisely spent? Whether you use it for the
ehci_hcd bug or any other HW related bug in the future? I am sure kernel
devs upstream would be happy to whitelist/blacklist autosuspend
accordingly if they were provided a detailed list for whom, wouldn't
they?

I'd be delighted if you would share your thoughts on the feature I
proposed for launchpad as well as on whether or not it could be a viable
solution to whitelist/blacklist autosuspend in kernel if the proper
information would be available for whom.

On Mon, 2008-02-04 at 21:13 +0000, Ben ...

[Pär Lidén (par-liden)]

@Elias: I don't mean to sound rude, but it feels for me that you have no
problem complaining about what others should and should not do, but then you
are yourself not ready to do much about it. Well, you might say that Ubuntu
is a proprietary project, because there is a corporation behind it, but all
code it produces are completely free and open-source. Many developers work
totatally for free on Ubuntu.

I suggest that instead of telling others what to do, you just go ahead and
do it yourself. I understand that you may not have the time for that, but
maybe you would then understand that other people (the paid developers) also
has a lot of other work to do, and maybe does not have time for your
favorite issue?

And regarding bug 3382: Yes, I agree with you, it sounds like a good idea,
great thinking from you Elias. But, please, I ask you, could you stop
posting about it here in this bug? I at least would be happy if you
wouldn't. You have already posted about it many times here, you don't need
to post it again. I think the message has gone through clear to everyone
here.

Also, if you would to like to support the developers in some way to do a
better job, you would be much better of giving words of encouragement,
instead of words of complain. I am totally sure that you criticising them
won't give them any more energy (and definitely not any more time) to work
on development.

This is meant as a friendly advice, I hope you don't feel dismayed or
something.

I also want take the opportunity to thank the developers for all the hard
work they are doing, from which I can benefit completely for free.

2008/2/9, Elias Humbolt <email address hidden>:
>
> @Ben Collins
>
> Ben, I am happy that somebody from Ubuntu is finally reacting to this
> Bug report. If not for fixing it than at least with an official
> statement what devs are actually thinking about the issue. And why
> obvious simple measures are not taken.
>
> Your argumentations surely is not bare any logic. My first reaction
> however was, well if suspend/resume is ought to be broken after
> removing/disabling the autosuspend feature, why can I still successfully
> suspend/resume on my laptop after disabling it. So now I have both, USB
> 2.0 and suspend/resume. You understand that some doubts did arise in me
> about your claim removal of autosuspend might screw up suspend/resume
> for many people.
>
> However, these doubts do not have many grounds just yet, except for my
> single perception on one type of system. Therefore I presume what you
> are claiming are well tested facts.
>
> I am wondering however, if it would not be possible to enable
> autosuspend for the one crowd of chipsets while disabling it for the
> other. Sure, not an easy task to identify, which systems to enable and
> which not.
>
> Extracting all this information from bug reports surly is hell. And yet,
> if you have talked everybody into submitting their data "again", you
> still will have to ask all of them to test whether or not disabling
> autosuspend breaks suspend/resume for them. This is a challenge for
> itslef. Undoable if you ask me, at least with the tools available.
>
> I therefore understand, why literally not...

[Markus Kienast (elias1884)]

@Pär

I don't feel offended but misunderstood. Partly that comes from the
fact, that some of your presumptions are wrong. Lets get them
straightened first:

1st: Whether was I saying that Ubuntu is proprietary not that the fact
that there is a cooperation behind it makes it any less free. Where did
you get that from?

2nd: Launchpad is to my knowledge neither OpenSouce nor FreeSoftware,
nor does it belong to Ubuntu! Launchpad is a proprietary product of
Canonical. Canonical is not Ubuntu! There were discussions about exactly
that issue when the software was first introduced. Google "launchpad
proprietary".

Ergo, Launchpad being neither OpenSource nor FreeSoftware pretty much
ties my hands. Even if I would want to add this feature into the
Launchpad eco-system, how would you suggest I do that with no access at
all? So for that part, I can only tell, not code.

You need to know that to understand the feature request part of my
comment.

So much to the facts you got wrong.
-----

So now to the misunderstanding part. Where am I exactly complaining?

I said:
Disabling autosuspend does not break suspend/resume for me, but that
does not mean much.
I understand this bug is hard to fix without more detailed info.
Only way to get more info is a HW-DB enabled poll feature.
I have no way to implement that, as Launchpad is ClosedSource.
But I am happy to share my idea with anyone enabled to implement it.
And I'd also get my own hands dirty, if Canonical wants to sponsor that
feature.

Does sound like a bunch of perceptions and suggestions to me, no
complains to be found.

Anyhow, let's discuss this further off the list, unless you have any
comments or suggestions on the bug itself and how to fix it.

On Sat, 2008-02-09 at 11:13 +0000, Pär Lidén wrote:
> @Elias: I don't mean to sound rude, but it feels for me that you have no
> problem complaining about what others should and should not do, but then you
> are yourself not ready to do much about it. Well, you might say that Ubuntu
> is a proprietary project, because there is a corporation behind it, but all
> code it produces are completely free and open-source. Many developers work
> totatally for free on Ubuntu.
>
> I suggest that instead of telling others what to do, you just go ahead and
> do it yourself. I understand that you may not have the time for that, but
> maybe you would then understand that other people (the paid developers) also
> has a lot of other work to do, and maybe does not have time for your
> favorite issue?
>
> And regarding bug 3382: Yes, I agree with you, it sounds like a good idea,
> great thinking from you Elias. But, please, I ask you, could you stop
> posting about it here in this bug? I at least would be happy if you
> wouldn't. You have already posted about it many times here, you don't need
> to post it again. I think the message has gone through clear to everyone
> here.
>
> Also, if you would to like to support the developers in some way to do a
> better job, you would be much better of giving words of encouragement,
> instead of words of complain. I am totally sure that you criticising them
> won't give them any more energy (and definitely not any more time) to wo...

[rod singleton (rod40cool)]

Exactly the same problem/symptoms is happening to me too. Modprob -r ehci_hcd corrects but USB transfer rate slow.
Linux rod-desk64 2.6.22-14-generic #1 SMP Thu Jan 31 23:33:13 UTC 2008 x86_64 GNU/Linux

Rod

[Robert North (russetrob)]

Why is this flagged wontfix?

Still a show stopper for people like me.
Has discouraged at least one potential Linux user I know.
Has certainly discouraged me from promoting Linux commercially.

This bug does need to be divided up into a number of distinct bugs, depending on symptoms, and which work-around eliminates the bug.

I personally would fix this, (at least for the symptoms I see)..... if I had 2 weeks full time to apply to it.
Unfortunately I do not, so I am at your mercy.

Maybe at least a mention in the release notes, and some suggestions of workarounds may be useful.

Please give guidance.

[Markus Kienast (elias1884)]

Has this issues been promoted upstream to the kernel bug tracker?

[Pär Lidén (par-liden)]

From what I've seen on another (GNOME) bug, some of the info entered in the
LP bug was also forwarded to gnome bugzilla by the developer. But I don't
think this always happens though.

For those of you here who are really interested in getting the bug fixed, I
strongly recommend you should report it yourself upstream. You might look at
this link for more info on that:
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. From what I've seen, the
kernel developers are generally much more responsive about bug reports than
the ubuntu developers.

But you have to test with the upstream kernel versions for that, and follow
their guidelines for reporting bugs. This might be helpful:
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html. You also have
to enable some debugging in the compilation, I think there is an USB_DEBUG
option or similar. Probably this bug exists in many flavors, one is where
USB_SUSPEND is the cause, but there are many others.

Some of you have reported that it worked with a certain kernel version, but
then stopped working. If you can find out precisely at what upstream -git
version it broke, you have probably come a long way towards fixing the bug.
But it is a lot of work in testing out that of course, and trying many
different versions until you nail down the correct one.

Comments
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/79and
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/177above
lists some of the upstream bugs about this, which might be helpful.

[John Zero (johnzero)]

Wow! Has this bug really been fixed? (Or am I just lucky today?)

I just upgraded to the current Ubuntu Hardy (development) snapshot, and my external harddisk (USB 2.0) works, and it works at USB 2.0 speeds! Even ehci_hcd is loaded, too.

Kernel version: Linux ewa 2.6.24-8-386 #1 Thu Feb 14 20:00:28 UTC 2008 i686 GNU/Linux
I have an NVIDIA NForce2 motherboard:
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)

[nusigmaforce (doctorcelebro)]

Somebody asked on which version it used to work before it broke. For me, the last version was Gnome desktop 2.16.1 (Ubuntu Edgy Eft).

> From: <email address hidden>
> To: <email address hidden>
> Date: Sun, 17 Feb 2008 21:49:30 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> Wow! Has this bug really been fixed? (Or am I just lucky today?)
>
> I just upgraded to the current Ubuntu Hardy (development) snapshot, and
> my external harddisk (USB 2.0) works, and it works at USB 2.0 speeds!
> Even ehci_hcd is loaded, too.
>
> Kernel version: Linux ewa 2.6.24-8-386 #1 Thu Feb 14 20:00:28 UTC 2008 i686 GNU/Linux
> I have an NVIDIA NForce2 motherboard:
> 00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
> 00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
> 00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4)
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

[Robert North (russetrob)]

John:

It's quite possible.... was just checking what has changed in the kernel this weekend and found the following:

[PATCH] EHCI: add a short delay to the bus_suspend routine
Here it's released as a patch (10th Jan)
http://thread.gmane.org/gmane.linux.usb.general/547

And here it goes into the mainline git (1st of feb, same day as alpha 4 was released.):
http://thread.gmane.org/gmane.linux.usb.general/1034

I'll be waiting for alpha 5 before testing this.

[Oisín Mac Fhearaí (denpashogai)]

So after all that, the whole problem was fixed with two lines of code?

On 18/02/2008, Robert North <email address hidden> wrote:
> John:
>
> It's quite possible.... was just checking what has changed in the kernel
> this weekend and found the following:
>
> [PATCH] EHCI: add a short delay to the bus_suspend routine
> Here it's released as a patch (10th Jan)
> http://thread.gmane.org/gmane.linux.usb.general/547
>
> And here it goes into the mainline git (1st of feb, same day as alpha 4 was released.):
> http://thread.gmane.org/gmane.linux.usb.general/1034
>
> I'll be waiting for alpha 5 before testing this.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[nusigmaforce (doctorcelebro)]

I'll test Alpha 5 as well and let you know, unless somebody beats me to it.

> From: <email address hidden>
> To: <email address hidden>
> Date: Mon, 18 Feb 2008 12:02:16 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> John:
>
> It's quite possible.... was just checking what has changed in the kernel
> this weekend and found the following:
>
> [PATCH] EHCI: add a short delay to the bus_suspend routine
> Here it's released as a patch (10th Jan)
> http://thread.gmane.org/gmane.linux.usb.general/547
>
> And here it goes into the mainline git (1st of feb, same day as alpha 4 was released.):
> http://thread.gmane.org/gmane.linux.usb.general/1034
>
> I'll be waiting for alpha 5 before testing this.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/

[Robert North (russetrob)]

I've tested with alpha 5 live CD, and still get the same errors.

So.... either John's bug is different from mine, or the kernel he used isn't in alpha 5.

John:
    Could you try alpha 5 live CD and see if it works?

[Ric Flomag (ricflomag)]

Tomorrow (March 6) is a Hug day dedicated to kernel bugs. This is be the occasion to try and investigate this bug. I won't be able to attend, but i hope that someone will (This is the main point of my message ;-)

I have reported Bug #144100 (check it, it has all the debug info), which i have marked later as duplicate of this one. The usb drive i was using then did not even mount. I have now another drive, it mounts but randomly disconnects. Disabling ehci_hcd is the only workaround.

I've tried echo -n -1 > /sys/module/usbcore/parameters/autosuspend with no luck.

Hardy Alpha 5 doesn't fix the problem either.

Why is this bug marked as "Won't fix" ?

[Robert North (russetrob)]

Ric:

Try the procedure described in my comment here, to put autosuspend in the boot procedure:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209
Sometimes not all devices seem to recover properly after turning off autosuspend.

I suspect we could divide this bug in two....

A. A bug where autosuspend disable fixes problems.

B. A bug where autosuspend disable has no effect whatsoever.

[Robert North (russetrob)]

P.s. Ric:

Can you try to find out more about why the bug is marked "Won't fix?"

I'm tempted to open a bug for case "A", so at least the case I'm seeing can progress towards a fix.

[Ric Flomag (ricflomag)]

Robert:

Yes I did try your procedure too, no luck.
As for the "Won't fix" stamp, the log says that we should ask Henrik :)

[Pär Lidén (par-liden)]

I think the rationale for the "won'f fix" stamp is that the kernel team
deamed it unlikely tha this bug would get fixed in time for Hardy. Probably
they will try to fix it for later Ubuntu versions (hopefully the 8.10). So
the "won't fix" stamp should probably be read as: won't fix for Hardy, if
I've understood things correctly.

2008/3/5, Ric Flomag <email address hidden>:
>
> Robert:
>
> Yes I did try your procedure too, no luck.
> As for the "Won't fix" stamp, the log says that we should ask Henrik :)
>
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[stg (steve-garon-deactivatedaccount)]

I've been having that problem too with High speed usb device that reset...
I dunno if its too late to propose solutions but I found this thread http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-01/msg11666.html where the guy is having similar problem with kernel 2.6.24. Someone actually provided a fix right here http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-01/msg12257.html.

This might help fix the problem, unfortunatly I don't have the knowledge to test this. Can anyone test it ? It would be nice to have that fix for hardy's release since the bug is still there in hardy alpha 6...

[cafilubu (cafilubuma)]

I buy a new case for my intel 478 ich5 motherboard... before chanching to this new case usb worked at high speed without reset, note that now with the new case the problem is present only with the front usb ports. The motherboard usb from behid works without problems, right now I bring up my old case and take out the front usb from that case and they work without problems, no need to remove ehci_hcd, just the front usb of my new case (cheap one:), now I tested the usb from the new case with slax 6.0 and they worked (in ubuntu they dont work only the ones from my old case).

Ubuntu 7.10 Gutsy - Kernel Linux 2.6.22-14-generic

[zub (zub1-uk)]

I would just like to add what I am seeing, I am also running Ubuntu 7.10 Gutsy - Kernel Linux 2.6.22-14-generic on an HP 6715b laptop with the AMD M690T chipset. I am getting the reset problem when trying to write to flash based memory sticks. I have tried to disable the autosuspend as mentioned above but with no effect. However I do have a 500gb usb hard drive and a battery powered 20gb hard drive and these both seem to work fine, so i am only seeing the problem with unpowered devices.

[b (ben-ekran)]

Ok, so It looks like this is the problem I'm also having.

I have two questions:

1. I cannot yet confirm this bug because I've not unloaded the ehci_hcd module. This is because my usb drive is still connected. I umounted it with -l, and I'm still seeing I/O errors in the syslog. fuser and lsof show me there are no processes that are still running on the device.

Is there anyway I can force the kernel to just stop trying to write to the disk? Last time I rebooted in this state the shutdown scripts halted on these same errors, and I had to hard reset anyhow. Do I have any other options that just waiting until the I/O errors stop when it gets to the end of the disk? I've caused enough filesystem damage on this machine due to this bug, and would like to stop doing it.

2. can ehci_hcd be added to the kernel module blacklist so its not loaded on bootup?

Thanks,
B. Bogart

[Matt LaPaglia (mlapaglia)]

I'd just like to say I'm experiencing this problem as well:

https://bugs.launchpad.net/ubuntu/+bug/216150

It's unfortunate it doesn't work as it should. My device can do both MSC and MTP, but MTP doesn't work in gutsy or hardy, while MSC works in both (hardy if you modprobe -r).

[Daniel Gimpelevich (daniel-gimpelevich)]

I seem to have gotten to the bottom of this bug, at least in Hardy. There were reports above that this is peculiar to nVidia chipsets, but later, others reported the same thing on VIA and SiS, and I've seen it on ATI as well. What do these have in common? EHCI is the spec for USB 2.0, but the spec for 1.1 may be either UHCI or OHCI. EHCI hosts fall back to either UHCI or OHCI buses when a USB 1.1 device is detected. I'm betting all the machines where ehci-hcd.ko works properly have EHCI hosts that only fall back to UHCI, and the machines with problems have EHCI hosts that fall back to OHCI buses. In such a case, when Ubuntu's initramfs starts udev, ehci-hcd.ko and ohci-hcd.ko will both auto-load in a relatively unpredictable order. Problems arise when the EHCI bus has both a USB 2.0 multifunction device and a USB 2.0 hub through which a USB 1.1 device is connected at the time that this happens.

If ohci-hcd.ko loads first:
All devices connected are recognized as USB 1.1 devices, and when ehci-hcd.ko subsequently loads, the USB 2.0 devices among them register a disconnect and a reconnect as USB 2.0 devices. Everything is then fine for about a minute, after which a spontaneous USB reset is processed, and things go completely haywire, causing no USB device to be usable until a reboot.

If ehci-hcd.ko loads first:
Only USB 2.0 devices are recognized at all, until ohci-hcd.ko loads, when they are all recognized. Almost immediately, a spontaneous USB reset is processed, and things go completely haywire, but they resolve themselves as soon as all USB 1.1 devices are unplugged, and go haywire again when they are plugged back in.

There is no trouble if either there is no USB 2.0 multifunction device, or no USB 1.1 devices are connected through a USB 2.0 hub. There is some kind of software conflict between ehci-hcd.ko and ohci-hcd.ko, because this all works fine in FreeDOS with the BIOS's USB Legacy Support, as well as in another non-Linux OS that has EHCI and OHCI support.

[Denilson Sá (denilsonsa)]

I disagree with you, Daniel Gimpelevich. I think this issue also happens when devices are hot-plugged (i.e., after the boot has been completed).

Could someone else confirm this?

[Daniel Gimpelevich (daniel-gimpelevich)]

How is that disagreeing? I never said it happens _only_ on boot. My testing shows that it can happen at any time. It's just that, if they are already plugged in at boot, then you know it's going to happen. On a hotplug, it will happen then next time there is a USB bus-reset, by which time, it's easy to have forgotten that a device was hotplugged.

[rod singleton (rod40cool)]

I have read this bug with interest as I am also having the same problem (see my question #31020 https://answers.launchpad.net/ubuntu/+question/31020). I seem to have unluckily bought a new PC with a Gigabyte motherboard that contains the aforementioned nVidia USB chipset. :(
I have tried both the 64 bit generic and the rt kernel and the Live CD of the 32 bit Hardy and all have the same problem. I recently noticed that my USB 2 flash drive (memory stick) wont mount either now that I've upgraded to Hardy where previously this did in 7.04.

This might sound like a silly question but why isn't this bug going to be fixed given that it has existed since the kernel 2.6.20 and is still present in the latest kernel shipped with Hardy which is 2.6.24-16?

Does the bug exist in the kernel or is it specific to Ubuntu? If the kernel what is the process of reporting this bug to that team?

Regards
Rod

[Pete Myers (petemyers)]

I'm getting this problem with my Palm LifeDrive, and with my Arduino microcontroller board.

Neither device is even detected when connected with USB. A /dev isn't assigned.

The problem goes away when I sudo modprobe -r ehci_hcd.

I've documented some of my experiences with this bug on this thread:
http://ubuntuforums.org/showthread.php?t=760518

Please fix! This is a terrible bug!

[Alexander Horz (info-horz)]

The bug was first reported more than one year ago. Additionally, so called "duplicates" max even be different bugs: I've already reported such a
similar but possibly different bug #184382 "ehci_hcd: usb disk detection requires un/loading" where also *loading* of ehci_hcd is a workaround.

I would very much prefer a general debugging strategy starting from a design document down to the actual implementation: Could you please give me pointers to
relevant documents, e.g. what *should* happen when plugging in a USB device -- beginning from an architectural point of view and ending at the actual implementation / source code level.

At a first glance, this approach seems to be annoying. However, even very experienced software experts like me absolutely have no (practical) chance of contributing to this bug (group ?), since most of us have no a priori knowledge of all the gory USB details at hardware and kernel implementation level.

Experience, i.e. bugs reports, tell us that USB support is not trivial. Provide a design document, please!

[Pete Myers (petemyers)]

Some of the stuff on here is out of date... but it's still *the* place to go:

http://www.linux-usb.org/

This is 3.5 years old, but is still the relevant page:

http://www.linux-usb.org/usb2.html

The maintainer of ehci_hcd is a guy called David Brownell. He's contactable on this email: <email address hidden>

[rod singleton (rod40cool)]

I think this bug is solved for me. The solution for me was to not use the front USB ports on the front of the case but instead plug my ipod into one of the usb ports on the back of the case which are directly mounted on the motherboard. I can only assume that the ipod was a bit temperamental with the front usb ports - may be it wasn't getting enough power, or the connecting cables provided with the case were sub-standard.

[Pete Myers (petemyers)]

Rod40cool:

How are the front usb ports different to the back usb ports exactly? Is it that they are usb ports from the motherboard, with an extension cable 'round to the front, or (crucially), are the usb ports on the front running from a card, and not from the motherboard?

[Perry E. Metzger (perry-piermont)]

rod40cool <email address hidden> writes:
> I think this bug is solved for me. The solution for me was to not use
> the front USB ports on the front of the case but instead plug my ipod
> into one of the usb ports on the back of the case which are directly
> mounted on the motherboard.

That's not a "solution". You're almost certainly just using the low
speed ports instead of the high speed ports. It should not be the case
that some people have difficulty using USB high speed.

Perry

[Daniel Gimpelevich (daniel-gimpelevich)]

On May 3, 2008, at 8:24 AM, Perry E. Metzger wrote:

> That's not a "solution". You're almost certainly just using the low
> speed ports instead of the high speed ports. It should not be the case
> that some people have difficulty using USB high speed.

That's what I originally suspected, but I verified that NOT to be the
case for him. Everything but the mouse was getting recognized as
high-speed devices, but the iPod was not communicating reliably when
plugged into the front. Thus, what he was experiencing was not even
this bug at all.

[Perry E. Metzger (perry-piermont)]

Daniel Gimpelevich <email address hidden> writes:
> On May 3, 2008, at 8:24 AM, Perry E. Metzger wrote:
>
>> That's not a "solution". You're almost certainly just using the low
>> speed ports instead of the high speed ports. It should not be the case
>> that some people have difficulty using USB high speed.
>
> That's what I originally suspected, but I verified that NOT to be the
> case for him. Everything but the mouse was getting recognized as
> high-speed devices, but the iPod was not communicating reliably when
> plugged into the front. Thus, what he was experiencing was not even
> this bug at all.

Bizarre. So he just had broken hardware?

[rod singleton (rod40cool)]

>Daniel Gimpelevich <email address hidden> writes:
>> On May 3, 2008, at 8:24 AM, Perry E. Metzger wrote:
>>
>>> That's not a "solution". You're almost certainly just using the low
>>> speed ports instead of the high speed ports. It should not be the case
>>> that some people have difficulty using USB high speed.
>>
>> That's what I originally suspected, but I verified that NOT to be the
>> case for him. Everything but the mouse was getting recognized as
>> high-speed devices, but the iPod was not communicating reliably when
>> plugged into the front. Thus, what he was experiencing was not even
>> this bug at all.
>
>Bizarre. So he just had broken hardware?

It's certainly a solution for me as I said to Daniel. I can't explain why but it's definitely connecting at High Speed now as mp3 transfer from Amarok is very fast now. The front USB ports connect via cables to the motherboard. My motherboard I don't mind sharing with you is http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ClassValue=Motherboard&ProductID=2507&ProductName=GA-M61SME-S2
The specs seem to indicate that all the usb ports front and rear are 2.0/1.1 speed. The only things that I can think of is the cables supplied with the rather cheap case to connect the front usb ports to the mb are sub standard and this is causing the fussy ipod to not getting exactly the right voltage. :)

[MountainX (dave-mountain)]

I am experiencing this bug in Ubuntu Hardy. I have the nVidia chipset in an Asus A8N5X motherboard. I had to turn off USB 2.0 support in the bios. I would like to get USB 2.0 back. This is a desktop computer so suspend/resume isn't used. Is the autosuspend=0 workaround still applicable to me?

2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 GNU/Linux

Here is my lspci (with USB 2.0 support turned off in the bios).

$ lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1)
05:06.0 Ethernet controller: Linksys Gigabit Network Adapter (rev 10)

[chiacchio (chiacchio)]

Hi everybody,

I have the same problem on a cheap notebook (Packard Bell EasyNote R1801) with Ubuntu Hardy. I noticed that two devices that I use conflict each other: the compact-wireless drivers and the USB 2.0 (IPod). I can get working just one of them. If I add to the boot line "noapic", USB works and the compat-wireless do not. The opposite happens when I delete "noapic". I hope this could be useful to someone to fix this bug...

Bye,

[NoWhereMan (e.vacchi) (uncommonnonsense)]

hi chiacchio,

I'm quite sure your problem is associated with this kernel bug
http://bugzilla.kernel.org/show_bug.cgi?id=8896#c127

the solution is applying a patch to the kernel; I can provide you with
the 2.6.25 kernel I'm currently using, if you want
you can contact me privately at uncommonnonsense [at] gmail [dot] com

On Sun, May 18, 2008 at 7:26 PM, chiacchio <email address hidden> wrote:
> Hi everybody,
>
> I have the same problem on a cheap notebook (Packard Bell EasyNote
> R1801) with Ubuntu Hardy. I noticed that two devices that I use conflict
> each other: the compact-wireless drivers and the USB 2.0 (IPod). I can
> get working just one of them. If I add to the boot line "noapic", USB
> works and the compat-wireless do not. The opposite happens when I delete
> "noapic". I hope this could be useful to someone to fix this bug...
>
> Bye,
>
> ** Attachment added: "lspci.txt"
> http://launchpadlibrarian.net/14589804/lspci.txt
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[chiacchio (chiacchio)]

Hi NoWhereMan,

I tried to contact you on your email, I didn't receive any reply (maybe your account consider my email as spam). Anyway can you give some more hints to solve my problem. Consider I have never patched or compiled a kernel before.... Thank you.

Chiacchio

[mafeu (m-feuersaenger)]

Hi Daniel Gimpelevich and further co-sufferers,

I'm as well plagued with this USB bug on all my machines for a long long while now and so far didn't see any solution.

Your description you posted on 2008-04-19 looked like a very promising approach. However, following your logic when removing the 1.1 modules (i.e. either uhci or ohci) than the resets should stop. Unfortunately I can't confirm such a behavior.

First let me post the facts
In fact, I'm right now at a computer with the following SIS chipset:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:09.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter

and running
root@bitola:/home/mafeu# uname -a
Linux bitola 2.6.24-2.6.24.4.slh.3-sidux-686 #1 SMP PREEMPT Mon Mar 31 14:37:59 UTC 2008 i686 GNU/Linux

(I know, this is not Ubuntu, but this bug seems to be at least in all Debian-derived and this page here is the best documentation I found so far)

I unplugged all USB devices so that I'm just left with one USB 2.0 device and the internal card reader

root@bitola:/home/mafeu# lsusb
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 1019:0c55 Elitegroup Computer Systems (ECS) USB Flash Reader, Desknote UCR-61S2B
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 003: ID 0e21:1000 Cowon Systems, Inc.
Bus 001 Device 001: ID 0000:0000

I guess this listing pretty much reflects the three 1.1 controllers and the one 2.0 controller.

The following output might also be interesting:

root@bitola:/home/mafeu# lsmod|grep hci
ohci_hcd 27780 0
ehci_hcd 36876 0
firewire_ohci 19456 0
firewire_core 44096 1 firewire_ohci
usbcore 140268 6 uvcvideo,usb_storage,libusual,ohci_hcd,ehci_hcd
ssb 35204 1 ohci_hcd

My thought was now, if I remove the ohci_hcd module the only leftover device is the USB 2.0 device and the suspected reset situations should not happen anymore. So:
root@bitola:/home/mafeu# modprobe -rv ohci_hcd
rmmod /lib/modules/2.6.24-2.6.24.4.slh.3-sidux-686/kernel/drivers/usb/host/ohci-hcd.ko
rmmod /lib/modules/2.6.24-2.6.24.4.slh.3-sidux-686/kernel...

[Markus Kienast (elias1884)]

Still see this bug in Hardy.

[magilus (magilus)]

I'm not quite sure why this has been closed as many people are suffering this problem.

[Hamish Downer (mishd)]

One workaround I've found is to use an external USB hub. This won't work for everyone I imagine, but I was inspired to try by one of the above comments. It may work for you if, like me:

* most devices work OK with USB2
* you have one device that doesn't (MP3 players seem to be the common one)

In this case plug the MP3 player (or whatever the device is) into an external USB hub (pretty cheap) and try that without having to rmmod ehci_hcd ...

Hope this helps some of you.

Martin Jurgens: The reason why it was "won't fix" is explained by Ben Collins above
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/228
Basically fixing this would break suspend for an equally large amount of people.

[Oisín Mac Fhearaí (denpashogai)]

On 30/05/2008, mish <email address hidden> wrote:
> One workaround I've found is to use an external USB hub. This won't
> work for everyone I imagine, but I was inspired to try by one of the
> above comments. It may work for you if, like me:
>
> * most devices work OK with USB2
> * you have one device that doesn't (MP3 players seem to be the common one)
>
> In this case plug the MP3 player (or whatever the device is) into an
> external USB hub (pretty cheap) and try that without having to rmmod
> ehci_hcd ...

I encountered the problem on a USB wireless adapter which was plugged
into an external USB hub. It didn't seem to make a difference what it
was plugged into.

Hard to believe this bug hasn't been fixed yet tbh. There's obviously
some workaround which allows other operating systems to deal with it
and suspend/resume normally as well.

Oisín

[Perry E. Metzger (perry-piermont)]

Oisín Mac Fhearaí <email address hidden> writes:
> Hard to believe this bug hasn't been fixed yet tbh. There's obviously
> some workaround which allows other operating systems to deal with it
> and suspend/resume normally as well.

A number of OSes seem to manage it just fine, yes.

Perry

[Matt LaPaglia (mlapaglia)]

Why is this not going to be fixed?

[Mackenzie Morgan (maco.m)]

This is a new bug for me as of Hardy. And rmmod'ing ehci_hcd doesn't help any. It makes it worse, even. It totally kills my USB ports so that syslog/dmesg/etc show absolutely nothing when the USB device is plugged in instead of throwing an error. Re modprobing ehci_hcd doesn't bring it back either. Syslog *says* my USB ports are back, of course, but they're still altogether non-functional, not recognizing that anything's been plugged in. The ehci stuff happened quite a long time ago, though, didn't it? Why would I only start experiencing this bug with Hardy?

[Perry E. Metzger (perry-piermont)]

Mackenzie Morgan <email address hidden> writes:
> This is a new bug for me as of Hardy. And rmmod'ing ehci_hcd doesn't
> help any. It makes it worse, even.

Then it might not be the same bug.

Perry

[jnygaard (jens-olav-nygaard)]

> Why is this not going to be fixed?

It's not a particularly sexy problem...

[Matt LaPaglia (mlapaglia)]

A sexy problem lol? I mean, it's a bug that's been around since feisty, it's already a women in her 60's!

[Sapan (sapan-ganguly-gmail)]

I still have this problem too. 2.6.20-16-generic #2 SMP Tue Feb 12 02:11:24 UTC 2008 x86_64 GNU/Linux

[oasisfai (leong-kuong-fai)]

I also have this problem when connect my sony psp to hardy.

2.6.24-19-generic #1 SMP Wed Jun 4 15:10:52 UTC 2008 x86_64 GNU/Linux

[blubbi (torsten-steiner)]

Problem still persists. (Gutsy) I will upgrade to hardy and check again.

[nusigmaforce (doctorcelebro)]

Don't bother. Hardy has the problem too.

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Sat, 21 Jun 2008 10:56:52 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> Problem still persists. (Gutsy) I will upgrade to hardy and check again.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Earn cashback on your purchases with Live Search - the search that pays you back!
http://search.live.com/cashback/?&pkw=form=MIJAAF/publ=HMTGL/crea=earncashback

[Denilson Sá (denilsonsa)]

This is a bug in linux kernel itself, and can happen on any distribution. I've myself experienced this bug in Gentoo/Linux.

However, this bug appears to happen only in some hardware configurations. On my old Pentium III 800, Via chipset with on-board USB 1.x, plus an Ali USB 2.0 PCI card, it always happened. On my new Asus M51Sn laptop, it looks like it does not happen (but I haven't stressed it too much, so I'm not sure). I'm also pretty sure that Asus Eee PC does not have this bug.

[aschuring (aelschuring)]

I thought I'd chime in as well. This bug is old, seeing as how Bug #54273 is essentially the same bug. However, I have not been hit hard by this bug until today, under:
root@neminis:~# uname -a
Linux neminis 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

My symptoms are a bit strange, though: I have no problems with my usb-2.0 external harddisk, but instead, Ubuntu fails to recognize my (usb-1.1) mouse until I unload the ehci module. Also, after various plug-in-and-out attempts I had my mouse activated, but pressing ctrl+alt+f7 to return to X caused an USB reset on all hubs, and killed my mouse again. By now, I'm guessing it's a timing-related issue, seeing as how a VT switch always causes a 2-second hang on my machine (I'm using the radeon driver, not fglrx). I'm not familiar with the usb protocol specs, but is it possible that the ehci driver sometimes fails to respond in a timely fashion?

I'm attaching my lspci output. Needless to say, I have not changed any hardware since the last kernel upgrade. I did before have issues with my mouse not activating after a reboot, but that was always fixed by a plug-out-and-in sequence. Until the last update, that is.

[aschuring (aelschuring)]

USB events since boot sequence:

[26] both ohci and ehci drivers loaded
[27] ehci recognizes and activates LaCie external disk
[28] ohci fails to activate mouse
[160] plug-out-and-in logitech mouse; no recourse
[570] rmmod ehci-hcd
[571] ohci activates external disk on full speed
[613] plug-out-and-in mouse; mouse activated

root@neminis:~# lsusb
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 007: ID 046d:c00b Logitech, Inc. MouseMan Wheel
Bus 001 Device 006: ID 059f:100d LaCie, Ltd
Bus 001 Device 001: ID 0000:0000

[aschuring (aelschuring)]

I can confirm the workaround posted above, to connect the usb-1 devices via an external hub instead of directly on the root hub. Oddly enough, the usb hub I am using is usb-1 only; I would have expected the workaround to work only when using an usb-2 hub.

[andymc73-old (andymc73-old)]

I have just tried Ubuntu (8.04 amd64) for the first time, after having used stock Debian Etch for some years. I hit this problem almost straight away.

Motherboard: Gigabyte GA-MA69GM-S2H
Same basic dmesg output as reported for others so not posting yet again

Dual booting on the same PC, I don't get the problem in Debian 4.0r3. Presumably its as much the different kernel version as anything. So I will look into whats different if it is possible to do so.

[jnygaard (jens-olav-nygaard)]

andymc73, it may be that you are the first one to report having both a non-working and working Linux installation on exactly the same hardware at the same time, so your findings will be interesting. What kernel versions are the two installations using? (I would gladly revert to an older kernel if it would make my disks readable again. Contrary to some posters suggestions, reading/writing a couple of 500 GB disks with USB 1.1 is simply not practical...)

J.O.

[Antonio Batovanja (toni-toni)]

Any chance of fixing this bug any time soon?
I've filed an upstream bug:
http://bugzilla.kernel.org/show_bug.cgi?id=11030

2.6.24-19-generic, still there...

from lspci:
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)

from lsusb:
Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)

works with ohci_hcd. With ehci_hcd, I'm getting USB resets all the time.

[nusigmaforce (doctorcelebro)]

Honestly, I do not know what kind of proposed updates I installed in Hardy Heron, that now my USB Maxtor OneTouch II, that wasn't being recognized (not visible), is now working fine.

Axel Ramirez

The World's Best-Engineered PCs.
Lenovo: New World, New Thinking.
http://www.lenovovision.com/lv2/mediaplayer.php?fid=anthem

> From: <email address hidden>
> To: <email address hidden>
> Date: Thu, 3 Jul 2008 11:55:26 +0000
> Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices
>
> Any chance of fixing this bug any time soon?
> I've filed an upstream bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=11030
>
> 2.6.24-19-generic, still there...
>
> from lspci:
> 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
> 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
>
> from lsusb:
> Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)
>
> works with ohci_hcd. With ehci_hcd, I'm getting USB resets all the time.
>
> ** Bug watch added: Linux Kernel Bug Tracker #11030
> http://bugzilla.kernel.org/show_bug.cgi?id=11030
>
> ** Also affects: linux via
> http://bugzilla.kernel.org/show_bug.cgi?id=11030
> Importance: Unknown
> Status: Unknown
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.

_________________________________________________________________
Enter the Zune-A-Day Giveaway for your chance to win — day after day after day
http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V1

[FoolsRun (michael-delaney)]

I have solved this problem on my system by replacing my USB 2.0 PCI card.

I had this problem with multiple hard drives connected to a USB2.0 PCI card in my home "server" (just a headless desktop machine serving data and printers to my home network).

My old USB 2.0 card was a CompUSA brand card with an NEC chipset. I just replaced this with another no-name card which has a VIA chipset and the problem seems to have been solved!

I'm not sure how helpful this information will be, especially for those with onboard USB 2.0 problems, but perhaps this information could help developers narrow down the real issue.

[FoolsRun (michael-delaney)]

Forgot to mention that my machine is running Hardy with all current updates. Before replacing the USB card I tested to make sure the problem appeared by attempting to copy a large file over the network, powered down, swapped out the card, powered up and tested again and found the problem gone.

[Perry E. Metzger (perry-piermont)]

FoolsRun <email address hidden> writes:
> I have solved this problem on my system by replacing my USB 2.0 PCI
> card.

That's not practical if you have a laptop.

Perry

[FoolsRun (michael-delaney)]

No, of course it's not practical for laptops and I didn't mean to imply that it was. I thought my results might help narrow down the issue, though.

[Perry E. Metzger (perry-piermont)]

FoolsRun <email address hidden> writes:
> No, of course it's not practical for laptops and I didn't mean to imply
> that it was. I thought my results might help narrow down the issue,
> though.

I think, based on the information attached to this bug report, that
the bug is already well understood. The problem is getting someone to
take it seriously to do something about it.

--
Perry E. Metzger <email address hidden>

[jnygaard (jens-olav-nygaard)]

I also caved in and inserted a new pci-card with a USB 2.0 controller and some ports.

Two really surprising things happened: First, I would have thought it necessarry to disable the onboard (motherboard) USB controller, since that was the one not working with ehci_hcd. (I base this on the fact that I got the "reset-errors" even without using any USB devices connected to the ports, as if the host controller itself had problems...) This was not correct, even when this is enabled and ehci_hcd now loaded, everything works without a glitch, under high stress!

Second, I thought the onboard (motherboard) USB controller/ports would be useless after disabling the controller in BIOS for these. The really strange thing is that now (since I did not need to disable USB in BIOS I tested this) the onboard USB ports suddenly work at full speed also. I simply do not understand how this can be. It is as if the mere presence of the new controller causes the problem to go away...

[Markus Kienast (elias1884)]

@perry

Try pushing this bug on the kernel mailing list!

On Sat, 2008-07-05 at 18:34 +0000, Perry E. Metzger wrote:
> FoolsRun <email address hidden> writes:
> > No, of course it's not practical for laptops and I didn't mean to imply
> > that it was. I thought my results might help narrow down the issue,
> > though.
>
> I think, based on the information attached to this bug report, that
> the bug is already well understood. The problem is getting someone to
> take it seriously to do something about it.
>
> --
> Perry E. Metzger <email address hidden>
>

[andymc73-old (andymc73-old)]

Hi,

As it happends I havent bothered with Ubuntu again yet, I had to do real work so went back to my Etch setup :-)

I'm using a custom com,piled from Debian sources 2.6.25 kernel with the USB_SUSPEND option turned off.
On the weekend I'll get the specific versions, dpkg --list and kernel CONFIG etc.

--Andrew

----- Original Message ----
From: jnygaard <email address hidden>
To: <email address hidden>
Sent: Sunday, 29 June, 2008 5:29:19 PM
Subject: [Bug 88746] Re: ehci_hcd module causes I/O errors in USB 2.0 devices

andymc73, it may be that you are the first one to report having both a
non-working and working Linux installation on exactly the same hardware
at the same time, so your findings will be interesting. What kernel
versions are the two installations using? (I would gladly revert to an
older kernel if it would make my disks readable again. Contrary to some
posters suggestions, reading/writing a couple of 500 GB disks with USB
1.1 is simply not practical...)

J.O.

--
ehci_hcd module causes I/O errors in USB 2.0 devices
https://bugs.launchpad.net/bugs/88746
You received this bug notification because you are a direct subscriber
of the bug.

Status in Source Package "linux" in Ubuntu: Won't Fix
Status in Source Package "linux-source-2.6.20" in Ubuntu: Won't Fix
Status in Source Package "linux-source-2.6.22" in Ubuntu: Won't Fix
Status in linux in Ubuntu Hardy: Confirmed
Status in linux-source-2.6.20 in Ubuntu Hardy: Won't Fix
Status in linux-source-2.6.22 in Ubuntu Hardy: Won't Fix
Status in Source Package "linux-source-2.6.22" in Baltix GNU/Linux: Invalid

Bug description:
Certain USB devices do not work properly, or do not work at all, while the ehci_hcd module is loaded.

A solution is to unload the ehci_hcd module, which is loaded every time the computer starts, using the command 'sudo modprobe -r ehci_hcd'. This works fine but unfortunatly ehci-hcd is necessary for using USB 2.0, so you lose USB 2.0 features.
Another solution is to disable USB 2.0 through the BIOS setup.

With some devices it is possible to read files normally (ie. copy files from an USB pendrive to the computer), but the device disconnects abrubtly when you start writing data on the device. In some devices it fails after writing a certain amount of data, probably the size of the write cache.

Steps to reproduce:
1. Insert your USB 2.0 device (like a flash drive)
2. If the device is recognised and mounted properly try copying a file to it.
3. Comfirm with the 'dmesg' command that it isn't functioning properly. (I/O errors etc)
4. Remove the USB device
5. Unload ehci_hcd with 'sudo modprobe -r ehci_hcd'
6. Insert your USB device again.
7. Check that everything works. (copy some files, etc.)

      Start at the new Yahoo!7 for a better online experience. www.yahoo7.com.au

[jnygaard (jens-olav-nygaard)]

No hurry... I had to do real work myself, so I simply put in a new PCI-based USB host adapter, and voila, disks work at full speed...

J.O.

[aschuring (aelschuring)]

jnygaard wrote:
> No hurry... I had to do real work myself, so I simply put in a new PCI-
> based USB host adapter, and voila, disks work at full speed...
Just for clarification: are you saying that with a new card plugged in,
the old ports suddenly started playing nice to each other, or did you
move all (some) of your devices over to the new controller?

And FWIW, I don't think the problem is well understood yet; I'm not even
sure everything can be traced down to one bug. So far we have:

- several chipsets affected, all ohci-based
- problems only seem to appear when a slow and a fast device are
connected to the same usb controller
- some affected machines have problems with usb-1.1 devices (Al, me) -
they get error -62 in the logs
- some affected machines have problems with usb-2.0 devices (Martin,
Mika) - they get error -71 in the logs
- some machines exhibit spurious usb reset signals instead/as well

And several workarounds:
- unloading the ehci module allows all devices to work reliably (but slow)
- rearranging the devices (adding a hub, using a different port) can
give better results

J.O., would you be able to confirm if your devices still work if you
attach some of them to the new ports, and others to the old (I guess
on-board) ports?

[aschuring (aelschuring)]

According to some of the duplicates, this error appears with certain uhci chipsets as well, however the error in those cases seems to be error -110.

Also, I forgot to mention the workaround of disabling autosuspend. That also seems to work for only a few people (haven't tried it myself).

[jnygaard (jens-olav-nygaard)]

Yes: Old ports are suddenly playing nice.
I moved two devices to the new controller, one disk and
one host (Dell LCD screen) to which I again added two
disks. In addition, one disk is connected to an old port
(on the motherboard.)

All work with ehci_hcd at full speed. (About 20-30 MB/s
for these disks.) I have stressed the system by copying
large amounts (hundreds of GB) between all disks at the
same time, and it all work.

Note that before, all these disks, also those connected
via the LCD monitor, was not operated properly by the
kernel module. And as I said, even when the disks were
turned off, these "reset errors" were written to the logs,
from time to time.

Note that there are lots of chips & devices in my system,
Seagate, Maxtor and WD disks, USB hosts with Intel ICH9
and Via chips. The new PCI-card that "solved" the problem
has a Via-chip.

So, I guess I can confirm your last statement, even though
I have not tried different permutations of disks/ports. The
first permutation worked, which I take as a strong indication
that all others also will, since it was not picked specially.

J.O.

[Markus Kienast (elias1884)]

I can not stress enough, in case someone from Canonical is listening,
you will never master bugs like this, if you don't have proper
information about the hardware involved!

And there is only one way to assure you have that information:
Create a tool to collect the information on the host system.
Enable launchpad to attach this information to ones user account.

I would then have several machines HW data attached to my account.
When I report a bug, I would select which machines are affected.
Developers then should be offered a way to collect a list of affected HW
from the bug report.

I have posted an idea for this at brainstorm and a wishlist bug report
in launchpad and statements like this in several other bug reports. But
still Canonical/Ubuntu devs seem to prefer doing wild-guessing instead
of investigating with the proper tools!

Canonical should fund the development of this tool and it should be made
available to ALL projects and distributions for best results.

http://brainstorm.ubuntu.com/idea/1497/
https://bugs.launchpad.net/bugs/3382

[Antonio Batovanja (toni-toni)]

This bug is also present in kernel.org's 2.6.25.10 and 2.6.26-rc9 kernels.
Saying that, don't hold your breath for a quick fix.

[balihb (balihb-linux-kernel-bugs)]

Latest working kernel version:
Earliest failing kernel version:
Distribution: Debian/sid
Hardware Environment: ASUS M3A (AMD 770/SB600:http://www.asus.com/products.aspx?modelmenu=2&model=1934&l1=3&l2=149&l3=592&l4=0)
Software Environment:
Problem Description:
After using any usb2.0 device I have on my machine (only on linux, as on winxp there is no problem) for a few minutes I get this:
usb 6-5: reset high speed USB device using ehci_hcd and address 8
usb 6-5: device descriptor read/64, error -110
usb 6-5: device descriptor read/64, error -110
usb 6-5: reset high speed USB device using ehci_hcd and address 8
usb 6-5: device descriptor read/64, error -110
usb 6-5: device descriptor read/64, error -110
usb 6-5: reset high speed USB device using ehci_hcd and address 8
usb 6-5: device not accepting address 8, error -110
usb 6-5: reset high speed USB device using ehci_hcd and address 8
usb 6-5: device not accepting address 8, error -110
usb 6-5: USB disconnect, address 8
sd 4:0:0:0: Device offlined - not ready after error recovery
sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sdc, sector 530560
sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sdc, sector 530576
Buffer I/O error on device sdc1, logical block 138851
lost page write due to I/O error on sdc1
sd 4:0:0:0: [sdc] READ CAPACITY failed
sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:0: [sdc] Sense not available.
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] READ CAPACITY failed
sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:0: [sdc] Sense not available.
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:2: [sde] READ CAPACITY failed
sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:2: [sde] Sense not available.
sd 4:0:0:2: [sde] Write Protect is off
sd 4:0:0:2: [sde] Mode Sense: 00 00 00 00
sd 4:0:0:2: [sde] Assuming drive cache: write through
sd 4:0:0:1: [sdd] READ CAPACITY failed
sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:1: [sdd] Sense not available.
sd 4:0:0:1: [sdd] Write Protect is off
sd 4:0:0:1: [sdd] Mode Sense: 00 00 00 00
sd 4:0:0:1: [sdd] Assuming drive cache: write through
Buffer I/O error on device sdc1, logical block 138851
lost page write due to I/O error on sdc1
sd 4:0:0:3: [sdf] READ CAPACITY failed
sd 4:0:0:3: [sdf] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:3: [sdf] Sense not available.
sd 4:0:0:3: [sdf] Write Protect is off
sd 4:0:0:3: [sdf] Mode Sense: 00 00 00 00
sd 4:0:0:3: [sdf] Assuming drive cache: write through
sd 4:0:0:1: [sdd] READ CAPACITY failed
sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:1: [sdd] Sense not available.
sd 4:0:0:2: [sde] READ CAPACITY failed
sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
sd 4:0:0:2: [sde] Sense not available.
...
And after that nothing get recognized by the ehci module.

Steps to reproduce:

[balihb (balihb-linux-kernel-bugs)]

Created attachment 16976
dmesg

[balihb (balihb-linux-kernel-bugs)]

Created attachment 16977
kernel output (before and after)

[balihb (balihb-linux-kernel-bugs)]

Created attachment 16978
lsusb

after the ehci module get confused

[balihb (balihb-linux-kernel-bugs)]

Created attachment 16979
debug output

debug output with a kernel from git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
with:
CONFIG_USB_DEBUG=y
CONFIG_USB_STORAGE_DEBUG=y

[balihb (balihb-linux-kernel-bugs)]

The same problem present on
2.6.25-2-686 (from debian sid)
and
2.6.24 (but on 2.6.24, there is no error message, the ehci just stop working, but it takes longer to die)

[balihb (balihb-linux-kernel-bugs)]

Created attachment 16980
my kernel config

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 24 Jul 2008 22:45:58 -0700 (PDT) <email address hidden> wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11159
>
> Summary: reset high speed USB device using ehci_hcd
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.26
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: USB
> AssignedTo: <email address hidden>
> ReportedBy: <email address hidden>
>
>
> Latest working kernel version:
> Earliest failing kernel version:
> Distribution: Debian/sid
> Hardware Environment: ASUS M3A (AMD
>
> 770/SB600:http://www.asus.com/products.aspx?modelmenu=2&model=1934&l1=3&l2=149&l3=592&l4=0)
> Software Environment:
> Problem Description:
> After using any usb2.0 device I have on my machine (only on linux, as on
> winxp
> there is no problem) for a few minutes I get this:
> usb 6-5: reset high speed USB device using ehci_hcd and address 8
> usb 6-5: device descriptor read/64, error -110
> usb 6-5: device descriptor read/64, error -110
> usb 6-5: reset high speed USB device using ehci_hcd and address 8
> usb 6-5: device descriptor read/64, error -110
> usb 6-5: device descriptor read/64, error -110
> usb 6-5: reset high speed USB device using ehci_hcd and address 8
> usb 6-5: device not accepting address 8, error -110
> usb 6-5: reset high speed USB device using ehci_hcd and address 8
> usb 6-5: device not accepting address 8, error -110
> usb 6-5: USB disconnect, address 8
> sd 4:0:0:0: Device offlined - not ready after error recovery
> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
> end_request: I/O error, dev sdc, sector 530560
> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
> end_request: I/O error, dev sdc, sector 530576
> Buffer I/O error on device sdc1, logical block 138851
> lost page write due to I/O error on sdc1
> sd 4:0:0:0: [sdc] READ CAPACITY failed
> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
> sd 4:0:0:0: [sdc] Sense not available.
> sd 4:0:0:0: [sdc] Write Protect is off
> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
> sd 4:0:0:0: [sdc] Assuming drive cache: write through
> sd 4:0:0:0: [sdc] READ CAPACITY failed
> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
> sd 4:0:0:0: [sdc] Sense not available.
> sd 4:0:0:0: [sdc] Write Protect is off
> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
> sd 4:0:0:0: [sdc] Assuming drive cache: write through
> sd 4:0:0:2: [sde] READ CAPACITY failed
> sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
> sd 4:0:0:2: [sde] Sense not available.
> sd 4:0:0:2: [sde] Write Protect is off
> sd 4:0:0:2: [sde] Mode Sense: 00 00 00 00
> sd 4:0:0:2: [sde] Assuming drive cache: write through
> sd 4:0:0:1: [sdd] READ CAPACITY failed
> sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
> sd 4:0:0:1: [sdd] Sense not available.
> sd 4:0:0:1: [sdd] Write Protect is off
> sd 4:0:0:1: [sdd] Mode Sense: 00 00 00 00
> sd 4:0:0:1: [sdd] Assuming drive...

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

Hi,

On Thu, 24 Jul 2008 23:15:56 -0700, Andrew Morton
<email address hidden> wrote:
>> After using any usb2.0 device I have on my machine (only on linux, as on
> winxp
>> there is no problem) for a few minutes I get this:
>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>> usb 6-5: device descriptor read/64, error -110
>> usb 6-5: device descriptor read/64, error -110
>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>> usb 6-5: device descriptor read/64, error -110
>> usb 6-5: device descriptor read/64, error -110
>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>> usb 6-5: device not accepting address 8, error -110
>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>> usb 6-5: device not accepting address 8, error -110
>> usb 6-5: USB disconnect, address 8
>> sd 4:0:0:0: Device offlined - not ready after error recovery
>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>> end_request: I/O error, dev sdc, sector 530560
>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>> end_request: I/O error, dev sdc, sector 530576
>> Buffer I/O error on device sdc1, logical block 138851
>> lost page write due to I/O error on sdc1
>> sd 4:0:0:0: [sdc] READ CAPACITY failed
>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:0: [sdc] Sense not available.
>> sd 4:0:0:0: [sdc] Write Protect is off
>> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
>> sd 4:0:0:0: [sdc] Assuming drive cache: write through
>> sd 4:0:0:0: [sdc] READ CAPACITY failed
>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:0: [sdc] Sense not available.
>> sd 4:0:0:0: [sdc] Write Protect is off
>> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
>> sd 4:0:0:0: [sdc] Assuming drive cache: write through
>> sd 4:0:0:2: [sde] READ CAPACITY failed
>> sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:2: [sde] Sense not available.
>> sd 4:0:0:2: [sde] Write Protect is off
>> sd 4:0:0:2: [sde] Mode Sense: 00 00 00 00
>> sd 4:0:0:2: [sde] Assuming drive cache: write through
>> sd 4:0:0:1: [sdd] READ CAPACITY failed
>> sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:1: [sdd] Sense not available.
>> sd 4:0:0:1: [sdd] Write Protect is off
>> sd 4:0:0:1: [sdd] Mode Sense: 00 00 00 00
>> sd 4:0:0:1: [sdd] Assuming drive cache: write through
>> Buffer I/O error on device sdc1, logical block 138851
>> lost page write due to I/O error on sdc1
>> sd 4:0:0:3: [sdf] READ CAPACITY failed
>> sd 4:0:0:3: [sdf] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:3: [sdf] Sense not available.
>> sd 4:0:0:3: [sdf] Write Protect is off
>> sd 4:0:0:3: [sdf] Mode Sense: 00 00 00 00
>> sd 4:0:0:3: [sdf] Assuming drive cache: write through
>> sd 4:0:0:1: [sdd] READ CAPACITY failed
>> sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:1: [sdd] Sense not available.
>> sd 4:0:0:2: [sde] READ CAPACITY failed
>> sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
>> sd 4:0:0:2: [sde] Sense not available.

What were you doing with the device before it resets ?
If it was mounted and it somehow reset, it could be
even ...

[balihb (balihb-linux-kernel-bugs)]

On Fri, Jul 25, 2008 at 12:49, Felipe Balbi <email address hidden> wrote:
> Hi,
>
> On Thu, 24 Jul 2008 23:15:56 -0700, Andrew Morton
> <email address hidden> wrote:
>>> After using any usb2.0 device I have on my machine (only on linux, as on
>> winxp
>>> there is no problem) for a few minutes I get this:
>>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>>> usb 6-5: device descriptor read/64, error -110
>>> usb 6-5: device descriptor read/64, error -110
>>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>>> usb 6-5: device descriptor read/64, error -110
>>> usb 6-5: device descriptor read/64, error -110
>>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>>> usb 6-5: device not accepting address 8, error -110
>>> usb 6-5: reset high speed USB device using ehci_hcd and address 8
>>> usb 6-5: device not accepting address 8, error -110
>>> usb 6-5: USB disconnect, address 8
>>> sd 4:0:0:0: Device offlined - not ready after error recovery
>>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>>> end_request: I/O error, dev sdc, sector 530560
>>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>>> end_request: I/O error, dev sdc, sector 530576
>>> Buffer I/O error on device sdc1, logical block 138851
>>> lost page write due to I/O error on sdc1
>>> sd 4:0:0:0: [sdc] READ CAPACITY failed
>>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:0: [sdc] Sense not available.
>>> sd 4:0:0:0: [sdc] Write Protect is off
>>> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
>>> sd 4:0:0:0: [sdc] Assuming drive cache: write through
>>> sd 4:0:0:0: [sdc] READ CAPACITY failed
>>> sd 4:0:0:0: [sdc] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:0: [sdc] Sense not available.
>>> sd 4:0:0:0: [sdc] Write Protect is off
>>> sd 4:0:0:0: [sdc] Mode Sense: 00 00 00 00
>>> sd 4:0:0:0: [sdc] Assuming drive cache: write through
>>> sd 4:0:0:2: [sde] READ CAPACITY failed
>>> sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:2: [sde] Sense not available.
>>> sd 4:0:0:2: [sde] Write Protect is off
>>> sd 4:0:0:2: [sde] Mode Sense: 00 00 00 00
>>> sd 4:0:0:2: [sde] Assuming drive cache: write through
>>> sd 4:0:0:1: [sdd] READ CAPACITY failed
>>> sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:1: [sdd] Sense not available.
>>> sd 4:0:0:1: [sdd] Write Protect is off
>>> sd 4:0:0:1: [sdd] Mode Sense: 00 00 00 00
>>> sd 4:0:0:1: [sdd] Assuming drive cache: write through
>>> Buffer I/O error on device sdc1, logical block 138851
>>> lost page write due to I/O error on sdc1
>>> sd 4:0:0:3: [sdf] READ CAPACITY failed
>>> sd 4:0:0:3: [sdf] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:3: [sdf] Sense not available.
>>> sd 4:0:0:3: [sdf] Write Protect is off
>>> sd 4:0:0:3: [sdf] Mode Sense: 00 00 00 00
>>> sd 4:0:0:3: [sdf] Assuming drive cache: write through
>>> sd 4:0:0:1: [sdd] READ CAPACITY failed
>>> sd 4:0:0:1: [sdd] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:1: [sdd] Sense not available.
>>> sd 4:0:0:2: [sde] READ CAPACITY failed
>>> sd 4:0:0:2: [sde] Result: hostbyte=0x01 driverbyte=0x00
>>> sd 4:0:0:2: [sde] Sense not available.
>
> W...

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

Hi,

On Fri, 25 Jul 2008 12:58:41 +0200, "Balázs Hámorszky" <email address hidden>
wrote:
>> What were you doing with the device before it resets ?
>
> I was copying from it.

Can you rebuild your kernel with CONFIG_USB_DEBUG enabled ?

>> Check, also, that hald-addon-storage is probably polling
>> an unexistent /dev/sdX.
>
> how?

ps aux | grep hald-addon-storage

if any hald-addon-storage is polling after the device
has gone offline, you should see something like this:

root 5841 0.0 0.0 24156 1280 ? S Jul16 0:44
hald-addon-storage: polling /dev/scd0 (every 2 sec)

[balihb (balihb-linux-kernel-bugs)]

On Fri, Jul 25, 2008 at 13:01, Felipe Balbi <email address hidden> wrote:
> Hi,
>
> On Fri, 25 Jul 2008 12:58:41 +0200, "Bal

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

On Fri, 25 Jul 2008 13:15:11 +0200, "Balázs Hámorszky" <email address hidden>
wrote:

> I've already done it and attached to the bug report
> (http://bugzilla.kernel.org/show_bug.cgi?id=11159).

beats me... Don't have hw to test and the problem is not on the reset
I suppose. The reset happens probably because the device disconnects
before.

I suppose it's some sort of current spikes during copy operation.

Might be some "quirk" in AMD ehci only.

Dave, any comments ?

[stern (stern-linux-kernel-bugs)]

On Thu, 24 Jul 2008, Andrew Morton wrote:

> > http://bugzilla.kernel.org/show_bug.cgi?id=11159
> >
> > Summary: reset high speed USB device using ehci_hcd

> > After using any usb2.0 device I have on my machine (only on linux, as on
> winxp
> > there is no problem) for a few minutes I get this:
> > usb 6-5: reset high speed USB device using ehci_hcd and address 8
> > usb 6-5: device descriptor read/64, error -110
> > usb 6-5: device descriptor read/64, error -110
> > usb 6-5: reset high speed USB device using ehci_hcd and address 8
> > ...
> > And after that nothing get recognized by the ehci module.

What makes you think that nothing gets recognized by ehci-hcd? Did you
try unplugging the device and plugging it back in? Or did you try
plugging in another high-speed device?

What happens if you try the suggestion in
http://bugzilla.kernel.org/show_bug.cgi?id=9638#c34 ?

Alan Stern

[balihb (balihb-linux-kernel-bugs)]

On Fri, Jul 25, 2008 at 15:33, Alan Stern <email address hidden> wrote:
> What makes you think that nothing gets recognized by ehci-hcd? Did you
> try unplugging the device and plugging it back in? Or did you try
> plugging in another high-speed device?

in the attachment "kernel output (before and after)" after the ehci
failed with the card reader I've pluged in a pendrive, wich was only
recognised by ohci.
I've tried the unplugging other times a lot, but most of the time I've
got the descriptor read error.

>
> What happens if you try the suggestion in
> http://bugzilla.kernel.org/show_bug.cgi?id=9638#c34 ?

I will try.

>
> Alan Stern
>
>

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

On Friday 25 July 2008, Felipe Balbi wrote:
> Dave, any comments ?

No; doesn't happen for me, never seen it, I have no insights.

Beyond the fact that at least one recent failure seems to have been
caused by the device getting suspended during enumeration ...

[stern (stern-linux-kernel-bugs)]

On Fri, 25 Jul 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

On Sat, Jul 26, 2008 at 05:57, Alan Stern <email address hidden> wrote:
> On Fri, 25 Jul 2008, Bal

[stern (stern-linux-kernel-bugs)]

On Sun, 27 Jul 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

Created attachment 17009
ehci registers before

[balihb (balihb-linux-kernel-bugs)]

Created attachment 17010
ehci registers after

after pendrive attached and the ehci module went wrong

[xens (r-aviolat)]

I just can't believe it, with interpid ibex alpha 3 it's working like a charm!!!
Kernel: Linux xens-laptop 2.6.26-4-generic (Laptop IBM ThinkPad T40)

12mbit/s on external HDD W00t!!!!

[Denilson Sá (denilsonsa)]

12mbit/s? Isn't that the full-speed USB 1.0/1.1 max transfer rate?
USB 2.0 high-speed has a theoretical limit of 480mbit/s.

[balihb (balihb-linux-kernel-bugs)]

On Mon, Jul 28, 2008 at 00:16, Alan Stern <email address hidden> wrote:
> Let's say you have mounted a debugfs filesystem on /sys/kernel/debug
> and your EHCI controller is located at PCI address 0000:00:13.5. Then
> the files of interest are those located in
> /sys/kernel/debug/ehci/0000:00:13.5/.

I've attached the two registers file to the bugreport.

[stern (stern-linux-kernel-bugs)]

On Thu, 31 Jul 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

On Thu, Jul 31, 2008 at 18:06, Alan Stern <email address hidden> wrote:
> On Thu, 31 Jul 2008, Bal

[stern (stern-linux-kernel-bugs)]

On Thu, 31 Jul 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

On Thu, Jul 31, 2008 at 23:30, Alan Stern <email address hidden> wrote:
> That confirms the guess that your EHCI hardware has something wrong. I
> have no idea how or why it is able to work under Windows, though.

is it help anything if I make a log with:
http://benoit.papillault.free.fr/usbsnoop/index.php

or should I try with other OS? (BSD or Solaris)

[stern (stern-linux-kernel-bugs)]

On Thu, 31 Jul 2008, Bal

[anonymous (anonymous-linux-kernel-bugs)]

Reply-To: <email address hidden>

On Thursday 31 July 2008, Alan Stern wrote:
> On Thu, 31 Jul 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

I've written a mail to asus. This was the REALLY useful answer:

Due to the facts that there are various versions of Linux system, we
cannot offer support for each version, could you please visit the
official website of the OS you are using, and check if there is
anything that help?

If you still have any problem or the problem still exists, please feel
free to contact me. Thank you for the support!

Best regards and have a nice day!

[stern (stern-linux-kernel-bugs)]

On Fri, 1 Aug 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

The hub doesn't help. When I've only copied from the pendrive (and
done du -s *) it worked but with different pendrive and coping to it:
usb 6-8.3: new high speed USB device using ehci_hcd and address 8
usb 6-8.3: configuration #1 chosen from 1 choice
usb 6-8.3: New USB device found, idVendor=13fe, idProduct=1d00
usb 6-8.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 6-8.3: Product: DataTraveler 2.0
usb 6-8.3: Manufacturer: Kingston
usb 6-8.3: SerialNumber: 5B6C13851DC0
Initializing USB Mass Storage driver...
scsi4 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 4:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: [sdc] 4030464 512-byte hardware sectors (2064 MB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] 4030464 512-byte hardware sectors (2064 MB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 4:0:0:0: [sdc] Attached SCSI removable disk
sd 4:0:0:0: Attached scsi generic sg3 type 0
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
sd 4:0:0:0: [sdc] Result: hostbyte=0x05 driverbyte=0x00
end_request: I/O error, dev sdc, sector 265
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: device descriptor read/all, error -110
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8
usb 6-8.3: reset high speed USB device using ehci_hcd and address 8

[evanchsa (evanchsa-linux-kernel-bugs)]

I have an SB600 chipset and am experiencing the same or similar problem.

I have a USB hard drive attached as well as a USB keyboard and mouse.

When I "exercise" the hard drive via:

for f in `seq 100`; do dd if=/dev/zero of=test bs=64k count=6000; done

One of two things happens:

1. My mouse dies and no amount of unplug/replug works
2. The mouse works but is choppy. The reset messages stop entering the log if I stop my hard drive exerciser command.

Excerpt from dmesg:

usb 1-2.6: new low speed USB device using ehci_hcd and address 4
usb 1-2.6: configuration #1 chosen from 1 choice
input: Logitech Inc. iFeel Mouse as /devices/pci0000:00/0000:00:13.5/usb1/1-2/1-2.6/1-2.6:1.0/input/input6
input,hidraw2: USB HID v1.00 Mouse [Logitech Inc. iFeel Mouse ] on usb-0000:00:13.5-2.6
usb 1-2.6: New USB device found, idVendor=046d, idProduct=c030
usb 1-2.6: New USB device strings: Mfr=4, Product=32, SerialNumber=0
usb 1-2.6: Product: iFeel Mouse
usb 1-2.6: Manufacturer: Logitech Inc.
process `skype' is using obsolete setsockopt SO_BSDCOMPAT
usb 1-3: new high speed USB device using ehci_hcd and address 5
usb 1-3: configuration #1 chosen from 1 choice
usb 1-3: New USB device found, idVendor=05e3, idProduct=0702
usb 1-3: New USB device strings: Mfr=2, Product=3, SerialNumber=0
usb 1-3: Product: USB Mass Storage Device
usb 1-3: Manufacturer: Genesyslogic
Initializing USB Mass Storage driver...
scsi6 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device scan complete
scsi 6:0:0:0: Direct-Access WDC WD32 00JB-00KFA0 0811 PQ: 0 ANSI: 0
sd 6:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 6:0:0:0: [sdb] Attached SCSI disk
sd 6:0:0:0: Attached scsi generic sg2 type 0
kjournald starting. Commit interval 5 seconds
EXT3 FS on sdb1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB device using ehci_hcd and address 4
usb 1-2.6: reset low speed USB dev...

[LewCPE (lewcpe)]

I confirmed that adding an USB hub fix this problem for me.

- My system is ThinkPad R61.
- Linux wason-thinkpad-r61 2.6.22-15-generic #1 SMP Fri Jul 11 19:25:33 UTC 2008 i686 GNU/Linux
- The USB hub is ID 05e3:0606 Genesys Logic, Inc.
- The USB HDD controller is ID 04b4:6830 Cypress Semiconductor Corp. USB-2.0 IDE Adapter

[Antonio Batovanja (toni-toni)]

My problem is solved, it was a hardware defect.
The new card reader (same model) works perfectly.

[Perry E. Metzger (perry-piermont)]

Bug Watch Updater <email address hidden> writes:
> ** Changed in: linux
> Status: Incomplete => Invalid

What!?!?!? Why was this changed to "Invalid"? It hits me almost every
day!

Perry

[TDB (michael-baranov)]

Hey!
Invalid? It's BROKEN!!!

[Perry E. Metzger (perry-piermont)]

TDB <email address hidden> writes:
> Hey!
> Invalid? It's BROKEN!!!

Not to mention that hundreds of people have had the problem, and a
dozen duplicate problem reports got merged into this one.

Perry

[balihb (balihb-linux-kernel-bugs)]

I've found the problem. If I detach my hub, ehci works great. on
windows I've used the pendrive while the hub was attached to another
usb port without a problem. and on linux ehci lasted longer if I've
attached the usb2.0 devices to the hub. but if I attache to another
port while the hub is attached, than the problem comes (but slower
with the 2.6.24 kernel).
so, if the hub is faulty, than why there is no problem with it on
windows? (at least I can use my usb2.0 devices again)

Regards,
 Bal

[stern (stern-linux-kernel-bugs)]

On Tue, 19 Aug 2008, Bal

[balihb (balihb-linux-kernel-bugs)]

On Tue, Aug 19, 2008 at 17:59, Alan Stern <email address hidden> wrote:
> It might be a problem with the wiring (i.e., crosstalk), not the hub.
> What happens if you use two USB 2.0 devices at the same time (with no
> hub)?

both of them works great.

>
> I can't answer your question because I don't know (1) if the hub
> really is faulty, (2) what is wrong with the hub, or (3) how Windows
> works internally.
>
> Alan Stern
>
>

[stern (stern-linux-kernel-bugs)]

On Tue, 19 Aug 2008, Bal

[evanchsa (evanchsa-linux-kernel-bugs)]

(In reply to comment #35)

> Okay, so probably the hub really is at fault. But I still don't know
> what's wrong with it. And more importantly, I don't know how it
> managed to crash the EHCI controller. That's really strange.
>
> Alan Stern

At the risk of declaring victory prematurely, I too had a USB hub attached which I have since removed and everything is working great.

My previous setup was:

* Direct attached to PC:
 - Disk
 - Keyboard
 - Hub

* Attached to HUB:
 - Dock for digital camera (off)
 - Corded mouse
 - iPod

In my previous setup the USB system would die when doing lots of disk access on the USB disk.

New setup is:

* Direct attached to PC:
 - Disk
 - Keyboard
 - Mouse

The system has been up and stable for hours wiht lots of very heavy activity on the disk.

The hub is currently plugged in to another machine (Win2k) and is working just fine.

Any ideas on what information I can provide?

Stephen

[Toby Dickenson (toby-tarind)]

FWIW I'm seeing this too. Also on nforce2 chipset. Recently upgraded from Dapper which did not show this problem.

[Troy R. (dsm-iv-tr)]

+1, affected here too.

Only started with the most recent kernel minor version upgrade on Hardy for me.

Removing the module form the running kernel solved the issue, but imo 12mbps is unacceptable for most tasks involving external disks, for example.

[Toby Dickenson (toby-tarind)]

I previously reported that USB devices were not working on my nforce2 system when connected via hub after a dapper to hardy upgrade. I had tried the suggested workarounds here and nothing helped *except* blacklisting ehci_hcd, So Ive been living with usb 1 speeds for a month :-( But now I have a fix...

Robert North has describes two implementations of the autosuspend workaround in this bug report. Firstly at https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/88746/comments/188 he suggests setting /sys/module/usbcore/parameters/autosuspend to -1 and reloading ehci-hcd. This is what I tested, and it did not help. After further debugging I independantly found a working solution which is identical to his second suggestion at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209. This involves including the setting in modprobe.d and rebooting.

The first solution was insufficient in my case because the value in /sys/module/usbcore/parameters/autosuspend is a default which is applied to newly detected devices, but reloading echi-hcd was insufficent to force the redetection of all my usb devices. A transcript of the first workaround:

root@dumpet:~# rmmod ehci_hcd
root@dumpet:~# echo -1>/sys/module/usbcore/parameters/autosuspend
root@dumpet:~# cat /sys/module/usbcore/parameters/autosuspend
-1
root@dumpet:~# modprobe ehci_hcd
root@dumpet:~# cat /sys/module/usbcore/parameters/autosuspend
-1
root@dumpet:~# find /sys/ -name "autosuspend"
/sys/devices/pci0000:00/0000:00:02.0/usb1/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.1/usb2/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.2/usb3/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.2/usb3/3-2/power/autosuspend
/sys/module/usbcore/parameters/autosuspend
root@dumpet:~# cat `find /sys/ -name "autosuspend"`
2
2
-1
-1
-1

Two devices were left using autosuspend. I can patch them manually to get a working system:

root@dumpet:~# echo -1 > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/autosuspend
root@dumpet:~# echo -1 > /sys/devices/pci0000:00/0000:00:02.1/usb2/power/autosuspend
root@dumpet:~# cat `find /sys/ -name "autosuspend"`
-1
-1
-1
-1
-1

Setting it in modprobe.d is much better because the option will be set sufficiently early that no devices ever have autosuspend turned on. That link again:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209

Robert described that second workaround as "to apply the workaround permanently", but it is obviously deeper than that.

I guess the default 2 second timeout on autosuspend may explain the various posts which say it _sometimes_ works.... I works if the device is inserted within 2 seconds of other usb activity.

[Troy R. (dsm-iv-tr)]

I wonder if it could be something to do specifically with USB-connected HDD's, since my other devices work just fine? The controller in the drive/enclosure, perhaps? I wouldn't know where to start to look there.

I tried what Toby tried as well, without success:
I had never tried actually disabling autosuspend, only unloading ehci-hcd. I applied the usbcore autosuspend module option to a file in modprobe.d/, rebuilt my initramfs, and shut down. On reboot, I tried investigating the contents of

find /sys/ -name "autosuspend" && cat `find /sys/ -name "autosuspend"`

on my system. All reported -1, which is autosuspend off (as was set by the usbcore module option). However, on access to my USB external hdd, the same symptoms occur - all usb activity halts. My mouse and keyboard fail to respond, and the machine they are connected to must be rebooted to bring them back up - a simple rmmod/modprobe combo doesn't do the trick to re-enable them.

If I unload the ehci-hcd module, everything is as it was before I tried the fix. I can use my mouse, keyboard, and external hdd.

[Toby Dickenson (toby-tarind)]

Ive been checking whether it is sufficient to disable autosuspend for a few specific devices on the nforce2 board, hoping to package an easier fix as a udev rule. In short, its not possible. I haven't been able to determine the full pattern, but I definitely also need to disable autosuspend on the powered hub (Belkin 050d:0237 - it has no problems with other machines), and some effects depend on whether autosuspend is enabled when the device is first scanned. For this nforce2 board, disabling autosuspend entirely through modprobe.d seems the appropriate fix.

[Kjetil Thuen (kjetil-thuen)]

Testing the intrepid ibex alpha 5 live cd (amd64 version), with the new 2.6.27 kernel, this problem seems to be gone! I just copied 355MB from an external harddrive in 13 seconds (approx 218Mbit/s). And no errors to be seen in the logs. This computer is using nVidia CK804 USB Controllers. None of the workarounds people have come up with in the discussions around this bug has worked on this box (apart from blacklisting ehci_hcd and living with the depressing speed.)

[alexsott (alexsott)]

Hello

Could someone confirm if this is the same/related issue:

>I am getting indefinite flood of messages like this:
>Jun 14 14:03:12 q kernel: [ 1351.951271] usb 1-1: new high speed USB device using ehci_hcd and address 96
>Jun 14 14:03:12 q kernel: [ 1352.102899] usb 1-1: new high speed USB device using ehci_hcd and address 97
>Jun 14 14:03:13 q kernel: [ 1352.254214] usb 1-1: new high speed USB device using ehci_hcd and address 98
>Jun 14 14:03:13 q kernel: [ 1352.405066] usb 1-1: new high speed USB device using ehci_hcd and address 99
>Jun 14 14:03:13 q kernel: [ 1352.555917] usb 1-1: new high speed USB device using ehci_hcd and address 100
>Jun 14 14:03:14 q kernel: [ 1352.856362] usb 1-1: new high speed USB device using ehci_hcd and address 101
>Jun 14 14:03:14 q kernel: [ 1353.188244] usb 1-1: new high speed USB device using ehci_hcd and address 102
>Jun 14 14:03:14 q kernel: [ 1353.520114] usb 1-1: new high speed USB device using ehci_hcd and address 103
>Jun 14 14:03:15 q kernel: [ 1353.850999] usb 1-1: new high speed USB device using ehci_hcd and address 104
>Jun 14 14:03:15 q kernel: [ 1354.124277] usb 1-1: new high speed USB device using ehci_hcd and address 105
>Jun 14 14:03:15 q kernel: [ 1354.395645] usb 1-1: new high speed USB device using ehci_hcd and address 106
>Jun 14 14:03:16 q kernel: [ 1354.667979] usb 1-1: new high speed USB device using ehci_hcd and address 107
>Jun 14 14:03:16 q kernel: [ 1354.937902] usb 1-1: new high speed USB device using ehci_hcd and address 108
>Jun 14 14:03:16 q kernel: [ 1355.210254] usb 1-1: new high speed USB device using ehci_hcd and address 109
>Jun 14 14:03:17 q kernel: [ 1355.480970] usb 1-1: new high speed USB device using ehci_hcd and address 110
>Jun 14 14:03:17 q kernel: [ 1355.727157] usb 1-1: new high speed USB device using ehci_hcd and address 111
>Jun 14 14:03:17 q kernel: [ 1355.998690] usb 1-1: new high speed USB device using ehci_hcd and address 112
>Jun 14 14:03:18 q kernel: [ 1356.269416] usb 1-1: new high speed USB device using ehci_hcd and address 113
>Jun 14 14:03:18 q kernel: [ 1356.541765] usb 1-1: new high speed USB device using ehci_hcd and address 114

Full text is here
http://ubuntuforums.org/showthread.php?t=829180

[MountainX (dave-mountain)]

@alexsott
Your error messages look the same as mine. I would also like to know if our issue is the same as this bug. I assumed it was.

[Perry E. Metzger (perry-piermont)]

alexsott <email address hidden> writes:
> Could someone confirm if this is the same/related issue:
>
>>I am getting indefinite flood of messages like this:
>>Jun 14 14:03:12 q kernel: [ 1351.951271] usb 1-1: new high speed USB device using ehci_hcd and address 96
>>Jun 14 14:03:12 q kernel: [ 1352.102899] usb 1-1: new high speed USB device using ehci_hcd and address 97
>>Jun 14 14:03:13 q kernel: [ 1352.254214] usb 1-1: new high speed USB device using ehci_hcd and address 98
>>Jun 14 14:03:13 q kernel: [ 1352.405066] usb 1-1: new high speed USB device using ehci_hcd and address 99

Same issue.

--
Perry E. Metzger <email address hidden>

[stern (stern-linux-kernel-bugs)]

At this point my best suggestion is that you install the latest 2.6.27-rc kernel with CONFIG_USB_DEBUG enabled, go back to your old setup with the hub, and wait to see what happens.

[AlfonSkunk (alfonskunk)]

Same problem in 2.6.27-rc3 kernel image on MB with nforce2 chipset.

downloaded from here: http://kernel.ubuntu.com/pub/next/2.6.27-rc3/

USB 2.0 works until "autosuspend" or "write in"...

I'll try Toby Dickerson method and will post the results (disabling autosuspend function).

Thanks!

[beccon (conrad-diskussion)]

I have an Acer Travelmate 5720 with a Crystal Eye built in webcam which works only sporadicly. This is a trace from the syslog. I opened Kopete and could see the image of the webcam. Then I closed it and reopened which resulted in freezing Kopete. While that I got the following syslog entries:

Sep 15 18:41:19 becconmobil kernel: [ 2027.451199] usb 3-1: new high speed USB device using ehci_hcd and address 15
Sep 15 18:41:19 becconmobil kernel: [ 2027.592376] usb 3-1: configuration #1 chosen from 1 choice
Sep 15 18:41:19 becconmobil kernel: [ 2027.592731] uvcvideo: Found UVC 1.00 device Acer CrystalEye webcam (064e:a101)
Sep 15 18:41:19 becconmobil NetworkManager: <debug> [1221496879.159130] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00').
Sep 15 18:41:19 becconmobil NetworkManager: <debug> [1221496879.330856] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if1').
Sep 15 18:41:19 becconmobil NetworkManager: <debug> [1221496879.373021] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if0').
Sep 15 18:41:19 becconmobil NetworkManager: <debug> [1221496879.403328] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if0_video4linux').
Sep 15 18:41:44 becconmobil ovpn-openvpn[5348]: RESOLVE: Cannot resolve host address: miradata.d2g.com: [HOST_NOT_FOUND] The specified host is unknown.
Sep 15 18:41:50 becconmobil kernel: [ 2054.866482] uvcvideo: Failed to query (1) UVC control 9 (unit 3) : -32 (exp. 2).
Sep 15 18:41:50 becconmobil kernel: [ 2054.953841] uvcvideo: Failed to query (1) UVC control 9 (unit 3) : -32 (exp. 2).
Sep 15 18:41:50 becconmobil kernel: [ 2054.970761] uvcvideo: Failed to query (1) UVC control 9 (unit 3) : -32 (exp. 2).
Sep 15 18:41:50 becconmobil kernel: [ 2055.273409] usb 3-1: USB disconnect, address 15
Sep 15 18:41:50 becconmobil NetworkManager: <debug> [1221496910.578523] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if0').
Sep 15 18:41:50 becconmobil NetworkManager: <debug> [1221496910.581498] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if1').
Sep 15 18:41:50 becconmobil NetworkManager: <debug> [1221496910.582698] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00').
Sep 15 18:41:50 becconmobil NetworkManager: <debug> [1221496910.584378] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_64e_a101_CN0314_OV03_VA_R02_00_00_if0_video4linux').
Sep 15 18:41:51 becconmobil kernel: [ 2055.786204] usb 1-1: new full speed USB device using uhci_hcd and address 3
Sep 15 18:41:51 becconmobil kernel: [ 2055.906143] usb 1-1: device descriptor read/64, error -71
Sep 15 18:41:51 becconmobil kernel: [ 2056.129996] usb 1-1: device descriptor read/64, error -71...

[phaidros (phaidros)]

Just tested with 2.6.27-3-generic on t41p and the issue is still the same:
- using ehci_hcd gives repeated:
Sep 16 00:53:59 tiber kernel: [ 236.312069] usb 4-3: new high speed USB device using ehci_hcd and address 25
Sep 16 00:54:02 tiber kernel: [ 239.432060] usb 4-3: new high speed USB device using ehci_hcd and address 41
[..]

- on one usb stick it falls back to uhci pretty soon:
Sep 16 00:56:11 tiber kernel: [ 368.588075] usb 2-1: new full speed USB device using uhci_hcd and address 10
Sep 16 00:56:11 tiber kernel: [ 368.736047] usb 2-1: not running at top speed; connect to a high speed hub
Sep 16 00:56:11 tiber kernel: [ 368.800930] usb 2-1: configuration #1 chosen from 1 choice

- on another the ehci message gets repeated around 50 times until it falls back.

so, it seems falling back to uhci works somehow. which is good, and its not the biggest showstopper anymore :)

but, falling back to uhci is not really nice if usb adapter *and* usb device are high speed (aka usb 2.0) devices :-/

I have to confess, I don't unterstand the problem in full depth yet, where exactly is the culprit we are looking for? kernel? and where exactly is to distinguish between suspend capabilities and high speed usb devices? (ben collins mentioned a decision which was taken about that ..)

I'm going to try LiveCD later. Just took the intrepid kernel in for testing now ..

[TheBigT (kerecsen-bigfoot)]

I have a Mio GPS device that suffers from the same problems, both with ehci_hcd and uhci_hcd (both as an SD card reader and when accessing the internal flash).

lsusb:
Bus 005 Device 005: ID 045e:ffff Microsoft Corp.

lspci:
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)

I tried the Intrepid Alpha 5 live CD, and it gave me the same result. I tried the autosuspend trick from post 209, no change. A year and a half and no fix (not even a diagnosis) in sight. Wow!

[TheBigT (kerecsen-bigfoot)]

I did find a workaround: remounting the errant device in sync mode solves the issue completely. The write speed is still a bit slower than on windows (around 700kB/s instead of 1500), but not as slow as USB 1.1.

The magic incantation:
sudo mount -o remount,sync /dev/sdh1

[0x3333 (terciofilho-gmail)]

Same issue here.

Dell machine with a CK804 chipset.

No way to work with external harddrive. No workaround worked.

Any news?

uname -a:
Linux servidor.local 2.6.24-19-server #1 SMP Sat Jul 12 00:40:01 UTC 2008 i686 GNU/Linux

[0x3333 (terciofilho-gmail)]

my lspci -vvnn

[alphalupus08 (guthlaf)]

At the moment I'm running OpenSUSE 11.0 with kernel 2.6.25.16-0.1-default (x86_64) and observe the same behaviour (USB Controller is an ATI S600, by the way).

Whenever I plug in any USB-2.0 device (hard disk, flash memory or external DVD burner - doesn't matter what)
it takes quite a while until the device is mounted, and all these guys are mounted only in full speed mode.

With usbview I can check, that the high speed devices are connected first to the EHCI hub and become accessible as soon as they are passed to one of the OHCIs.

The ehci_hcd seems to try hard to catch the devices, so I get the well-known messages.
Sep 18 14:34:44 faramir kernel: usb 6-1: new high speed USB device using ehci_hcd and address 3
Sep 18 14:34:59 faramir kernel: usb 6-1: device descriptor read/64, error -110
Sep 18 14:34:59 faramir kernel: usb 6-1: device descriptor read/64, error -110
Sep 18 14:35:15 faramir kernel: usb 6-1: new high speed USB device using ehci_hcd and address 4
Sep 18 14:35:30 faramir kernel: usb 6-1: device descriptor read/64, error -110
Sep 18 14:35:45 faramir kernel: usb 6-1: device descriptor read/64, error -110
Sep 18 14:35:45 faramir kernel: usb 6-1: new high speed USB device using ehci_hcd and address 5
Sep 18 14:35:56 faramir kernel: usb 6-1: device not accepting address 5, error -110
Sep 18 14:35:56 faramir kernel: usb 6-1: new high speed USB device using ehci_hcd and address 6
Sep 18 14:36:06 faramir kernel: usb 6-1: device not accepting address 6, error -110
Sep 18 14:36:06 faramir kernel: hub 6-0:1.0: unable to enumerate USB device on port 1
Sep 18 14:36:07 faramir kernel: usb 1-1: new full speed USB device using ohci_hcd and address 2
Sep 18 14:36:07 faramir kernel: usb 1-1: not running at top speed; connect to a high speed hub
Sep 18 14:36:07 faramir kernel: usb 1-1: configuration #1 chosen from 1 choice
Sep 18 14:36:07 faramir kernel: usb 1-1: New USB device found, idVendor=1058, idProduct=0702
Sep 18 14:36:07 faramir kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 18 14:36:07 faramir kernel: usb 1-1: Product: External HDD
Sep 18 14:36:07 faramir kernel: usb 1-1: Manufacturer: Western Digital

Is it meaningful that the error message changes betwenn address 4 and address 5 while the error code remains the same.

Yesterday I tried a kernel compiled on my on (2.6.26.5-default) -- no improvement at all.
Using kernel boot params "acpi=off noapic nohpet" etc. -- no effect.

I use the hard disk just for syncing with unison so I could live with that. But I am really embarassed for the low speed behaviour of my DVD burner :-(

[andrej (andrej-linux-kernel-bugs)]

A similar issue here on two machines:
1) Asus M2400N laptop
2) IBM xSeries 330 server with a NEC USB 2.0 controller (in PCI)

Kernel version: 2.6.26.5

The affected device is a new Samsung DVD writer. Badly slow access and dozens of damaged DVD+RWs (grrr...) are the most serious symptoms of this problem.

Resets appear in bunches of about 20 - 100 in the kernel log. There are no other error messages between two resets. (I did not switch any special debugging options on...) Resets occur approximately every 30 seconds. Some bunches of resets are followed by a fatal series of I/O errors and rewritable media destruction. In many cases, however, normal operation is resumed after minutes of resetting and waiting. (Which does not save the DVD+RW from destruction, as unexpected delays seem to be a problem, too.)

I saw some interesting backtarces complaining about bugs in the pktcdvd module. Unfortunately, they occured on a kernel tainted by tha madwifi ath_pci module. So I don't know whether I should post them here or not.

Will try the autosuspend experiment mentioned here [https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746], but I don't believe this could work. Autosuspend is disabled im my kernel config. Enabling it and then re-disabling it at run-time does not sound logical to me. But I would do just anything to get rid of this awful problem.

[andrej (andrej-linux-kernel-bugs)]

Ooops... The autosuspend trick did not help at all. The problem persists.

One more important fact: The failing USB communication is somewhat dangerous for the whole system when a UDF disk is mounted. I have already experienced several hard lockups where even the magic SysRq key did not help at all.

[PiedPiper (legit-neo)]

I have read this bug for a while now and I would like to throw something in the hat that noticed. If anything please consider it a little lateral thinking. The only problem I am having with my USB is after I connect devices to a USB Hub.

My integrated ports work fine but the USB HUB has always given me problems. I am going on my second hub. (I replaced it thinking it was the HUB) I was using USB Viewer to see what the EHCI Controller is doing.

I noticed that on some devices I have it assigns one Interface per configuration. However I decided to hot plug several devices where it showed that it created multiple interfaces (3 or more) per configuration. Additionally is these devices were running at full speed. Another think I notices is that there was only one EHCI Host Controller whereas I had 5 OHCI Host Controllers (I only have 4 internal ports and Each host handles 2 ports)

When the USB Hub is empty everything works fine. However if I plug anything to the USB HUB either it won't boot or it will crash. Even after I disconnect the devices.

No matter what I connect to the HUB, Quickcam Bluetooth Dongle Printer Keyboard and Mouse Gamepad I always get the same results.

Is there a way to limit the amount of interfaces or stop loading interfaces and or the control the speed of the devices?

I am a noob at this so please excuse my ignorance.

Here is the input on USB Viewer after connecting my Quickcam

gspca / snd-usb-audio
Speed: 12Mb/s (full)
USB Version: 1.10
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Vendor Id: 046d
Product Id: 08d8
Revision Number: 1.00

Config Number: 1
 Number of Interfaces: 3
 Attributes: a0
 MaxPower Needed: 100mA

 Interface Number: 0
  Name: gspca
  Alternate Number: 0
  Class: ff(vend.)
  Sub Class: ff
  Protocol: ff
  Number of Endpoints: 2

   Endpoint Address: 81
   Direction: in
   Attribute: 1
   Type: Isoc
   Max Packet Size: 0
   Interval: 1ms

   Endpoint Address: 82
   Direction: in
   Attribute: 3
   Type: Int.
   Max Packet Size: 8
   Interval: 10ms

 Interface Number: 0
  Name: gspca
  Alternate Number: 1
  Class: ff(vend.)
  Sub Class: ff
  Protocol: ff
  Number of Endpoints: 2

   Endpoint Address: 81
   Direction: in
   Attribute: 1
   Type: Isoc
   Max Packet Size: 128
   Interval: 1ms

   Endpoint Address: 82
   Direction: in
   Attribute: 3
   Type: Int.
   Max Packet Size: 8
   Interval: 10ms

 Interface Number: 0
  Name: gspca
  Alternate Number: 2
  Class: ff(vend.)
  Sub Class: ff
  Protocol: ff
  Number of Endpoints: 2

   Endpoint Address: 81
   Direction: in
   Attribute: 1
   Type: Isoc
   Max Packet Size: 192
   Interval: 1ms

   Endpoint Address: 82
   Direction: in
   Attribute: 3
   Type: Int.
   Max Packet Size: 8
   Interval: 10ms

 Interface Number: 0
  Name: gspca
  Alternate Number: 3
  Class: ff(vend.)
  Sub Class: ff
  Protocol: ff
  Number of Endpoints: 2

   Endpoint Address: 81
   Direction: in
   Attribute: 1
   Type: Isoc
   Max Packet Size: 256
   Interval: 1ms

   Endpoint Address: 82
   Direction: in
   Attribute: 3
   Type: Int.
   Max Packet Size: 8
   Interval: 10ms
Versu...

[Denilson Sá (denilsonsa)]

Answering to PiedPiper:
Configurations, Interfaces and Endpoints are the basic structures of an USB device. You can't limit or mess with those things, else the device will simply not work. As comparison, it is like limiting the number of legs that a horse (or maybe any animal) can have. You can't do that.

And about this bug being related to USB hubs... All I can say is that some hubs can help to trigger or "solve" the problem (I guess), but I think this bug also happens on devices connected directly to the host controller.

[stern (stern-linux-kernel-bugs)]

The other people found that removing their hubs fixed the problem. Does this work for you?

[AlfonSkunk (alfonskunk)]

I think the problem is the suspend-mode implementation. Once your USB2.0 "thing" enters on suspend mode it can't wake up.
This state (suspend) is only especificated for 2.0 (ehci) nor 1.0/1.1

Disabling the autosuspend function, things work well, or disabling ehci function works well too. Sometimes, recompining kernel with noapic (disable global autosuspend functions) sometimes works well (I guess I read it before)

[Denilson Sá (denilsonsa)]

What's more, I think this bug only happens on some types of hardware (some types of host controller).

[andrej (andrej-linux-kernel-bugs)]

I do not use any hub. The DVD writer is connected directly in both cases (on both machines). It was the only device connected via USB in the whole system at the time of the experiment. (More precisely: resets occur no matter if other USB devices are connected or not.)

[stern (stern-linux-kernel-bugs)]

Then your problem is different from the ones described in this bug report. You should start another bug report for it, or else just post a description of the problem on the linux-usb mailing list.

[AlfonSkunk (alfonskunk)]

Definetly, the Toby Dickerson's suggest works on NFORCE2 chipsets (tested on 5 different mobo/distro, kernels 2.6.22, 2.6.25 and 2.6.27)

3 steps:

1.- Find all devices created yet with autosuspend

# find /sys/ -name "autosuspend"
/sys/devices/pci0000:00/0000:00:02.0/usb1/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.1/usb2/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.2/usb3/power/autosuspend
/sys/devices/pci0000:00/0000:00:02.2/usb3/3-2/power/autosuspend
/sys/module/usbcore/parameters/autosuspend

and check his values

# cat `find /sys/ -name "autosuspend"`
2
2
2
2
2

2.- Change all of this values to -1

# echo -1 > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/autosuspend
# echo -1 > /sys/devices/pci0000:00/0000:00:02.1/usb2/power/autosuspend
# echo -1 > /sys/devices/pci0000:00/0000:00:02.2/usb3/power/autosuspend
# echo -1 > /sys/devices/pci0000:00/0000:00:02.2/usb3/3-2/power/autosuspend
# echo -1 > /sys/module/usbcore/parameters/autosuspend

3.- Test again all of those are -1

# cat `find /sys/ -name "autosuspend"`
-1
-1
-1
-1
-1

All my usb sticks, HDD and printers works with 2.0 specs without any fault.

I could better make a script, but this more understantable for fixing

Someone can try this with another "bugged" chipset?

All credits to Toby Dickerson!

PD: Sorry about my poor english!

[btanoue (btanoue)]

Hello,
I have another variation of the above solution.

In your menu.list file you can add a parameter to turn off autosuspend globally.

kernel /boot/vmlinuz-2.6.26-1-686 root=/dev/hdb2 ro vga=791 usbcore.autosuspend=-1

This in fact is the same as above, but you don't have to change each device. The above approach is great if its just a few devices.

I stumbled upon this about 1 year ago with a Samsung ML-2010 that would only print a few pages and stop. I couldn't figure it out. After some snooping, I found it was because the Samsung printer driver (which included a Linux CD, Kudos to you Samsung) didn't turn off autosuspend. I notified Samsung to have their Linux team add the printer to the blacklist but I guess it never happened.

As a result, I can print fine and my devices are working.

I started to look for the same error again with the 2.6.26 kernel from Debian and stumbled upon this post. Just thought I'd share some knowledge.

But a question:
Is usb storage broken in the 2.6.26 kernel now?
I've been getting some strange errors

Oct 2 16:41:37 mepis1 kernel: [10725.578559] sd 13:0:0:0: [sda] Attached SCSI disk
Oct 2 16:42:26 mepis1 kernel: [10778.689115] usb 9-4: reset high speed USB device using ehci_hcd and address 14
Oct 2 16:42:27 mepis1 kernel: [10779.523824] usb 9-4: reset high speed USB device using ehci_hcd and address 14
Oct 2 16:42:27 mepis1 kernel: [10779.675803] usb 9-4: device firmware changed
Oct 2 16:42:27 mepis1 kernel: [10779.675803] usb 9-4: USB disconnect, address 14
Oct 2 16:42:27 mepis1 kernel: [10779.675803] sd 13:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 kernel: [10779.675803] __ratelimit: 254086 messages suppressed
Oct 2 16:42:27 mepis1 kernel: [10779.675803] lost page write due to I/O error on sda1
Oct 2 16:42:27 mepis1 last message repeated 9 times
Oct 2 16:42:27 mepis1 kernel: [10779.675803] sd 13:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 last message repeated 8 times
Oct 2 16:42:27 mepis1 kernel: [10779.675866] sd 13:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 kernel: [10779.676182] sd 13:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 kernel: [10779.679806] sd 13:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 last message repeated 10 times
Oct 2 16:42:27 mepis1 kernel: [10779.680300] sd 13:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
Oct 2 16:42:27 mepis1 kernel: [10779.699905] sd 13:0:0:0: [sda] Result: hostbyt...

[Martin Lubich (mlubich)]

I am using kubuntu 8.04.1 and just recently upgraded my computer to a amd770/sb600 based system (Phenom9750, 8GB, 64bit).

I never had any problems with my old setup (AMD Athlon 1500+, VIA chipset). But after upgrading I started experiencing the above mentioned behaviour regarding usb 2.0 devices.
After a lot of investigation and finding the problem described in a lot of places ( but not very coherently) including several posts on the lkml I think this is partly a hardware related problem.

Until now, there is no REAL solution to this problem. All the solutions provided here or at other places are solutions which may work on a particular setup, but surely not for all.

I have now found the solution for my setup, which seems to confirm the hardware relation. I also had the behaviour, that as soon as a hub is attached , the problems started to occur. As this does not hint at a software problem I increased the voltage for my southbridge (sb600) by 0.1 volts, which my bios conveniently offers. This was done with the hypothesis, that the controller might operate electrically in an undefined area, where external devices may trigger a complete failure of the controller (which seems to be the case in all the reports).
Well, the increase in voltage did the trick for me. But, again, this is a fix for my setup. I just adds evidence that here is not a mere software problem at hand.

The interesting part would be now, to investigate the kernel changes in the 2.6 series which actually triggers this behaviour.

[Robert North (russetrob)]

Your power issues are interesting.
The motherboard I have done most testing on, has in the past had power issues, which were mainly cured by getting a high quality PSU.
So, turning off power management, (the fix that worked best for me) probably avoids stressing an under-powered USB controller.

[Troy R. (dsm-iv-tr)]

The system I experience the issue on is also an SB600 chipset, however, I have no way of increasing the voltage - Dell's BIOS doesn't give me that option (the laptop is a Vostro 1000).

[mitch (mitch-linux-kernel-bugs)]

I have a USB keyboard and mouse (running through a KVM) and if I try to use an external USB hard-drive or a USB pen-drive I encounter this same problem. The keyboard and mouse stop responding. The USB hard-drive or pen-drive also stops working. Pen-drives are almost always readable and sometimes writeable. Hard-drives are sometimes readable but never writeable.

I've tried hooking things up through hubs and I've used different motherboard ports and tried other cables and it makes no difference. Have also tried multiple USB devices and it again makes no difference. All these devices work without problem on other systems.

If I login to the system remotely and do:

   rmmod ehci_hcd
   sleep 3
   modprobe ehci_hcd

the keyboard and mouse will work once again.

I tried booting the latest Ubuntu 8.10 LiveCD beta (via a USB CD-Drive), which supposedly has kernel 2.6.27 and that failed also.

My error logs are similar to the ones others have posted but I can post some if it would help.

My system is:
openSuSE 11.0
Linux abc 2.6.25.16-0.1-default #1 SMP 2008-08-21 00:34:25 +0200
          x86_64 x86_64 x86_64 GNU/Linux
ASUS M3A32-MVP motherboard (AMD 790FX/SB600)
Phenom 9850
8GB RAM

[stern (stern-linux-kernel-bugs)]

Please attach the dmesg log from a kernel built with CONFIG_USB_DEBUG enabled. If possible, make it a 2.6.27-rc8 kernel.

[mitch (mitch-linux-kernel-bugs)]

Created attachment 18230
dmesg dump

[mitch (mitch-linux-kernel-bugs)]

Just noticed you wanted 2.6.27-rc8, I used 2.6.27-rc9 does that work?

Dmesg dump attached.

Sequence of events:
- Boot
- Connect 2 ssh sessions
- Turn on USB hard-drive
- Rsync a 1GB directory to the USB drive
- Rsync hangs and keyboard stop responding (assume mouse also but in runlevel 3)
- Ctrl-C the rsync
- Try to unmount the USB drive but it won't unmount
- Turn the USB drive power off then it unmounts ok
- Keyboard still not responding
- rmmod ehci_hcd
- modprobe ehci_hcd
- Keyboard now works again

[stern (stern-linux-kernel-bugs)]

I wonder why your OHCI root hubs aren't autosuspending. Could you mount a debugfs filesystem and then post the contents of the ohci/0000:00:13.0/registers file?

Getting back to the main problem... What happens if you plug the keyboard/mouse and the USB drive directly into the computer, and leave the two hubs disconnected?

And what happens if you plug the keyboard/mouse directly into the computer and plug the drive into one of the hubs?

[mitch (mitch-linux-kernel-bugs)]

Created attachment 18234
Dmesg and ohci registers

Sequence of events this time:
- KBD and USB drive connected direct, no hubs, works fine!
- KBD direct and USB drive connect to a DLink hub, works fine!
- Unmounted the USB drive.
- Plugged in the KVM (ATEN CS1784) which has a hub in it also.
  Keyboard still plugged in direct.
- Got the error=-110 message.
- Keyboard still working.
- Did a register dump here (reg-a-13.*.txt).
- Tried to connect the USB drive to the ATEN hub,
  system did not recognize it.
- Tried to connect the USB drive to the DLink hub again,
  system did not recognize it here either.
- Did another register dump here (reg-b-13.*.txt).
- Tried to remove the ehci_hcd module but it wouldn't unload.

I also tried another ATEN CS1784 KVM that I had but it turns out to be broken.

[stern (stern-linux-kernel-bugs)]

Created attachment 18245
Fix unending polling in OHCI

First things first. The attached patch will fix the OHCI problem.

Now on to the real issue. Your results so far definitely indicate that the ATEN KVM is the source of the problem. Did the KVM have any keyboard or mouse attached into it when you first plugged it in during the previous test?

If you plug both the USB drive and the keyboard into the DLink hub, leaving the KVM unplugged, do they work?

If you then plug in the KVM (with nothing attached), do they continue to work?

If you then plug a mouse or keyboard into the KVM, does everything continue to work?

[mitch (mitch-linux-kernel-bugs)]

I will apply the patch and run some tests.

Without a doubt the ATEN KVM triggers the problem, on this system, but on other systems it works without problems. Not a question, just wanted to re-iterate that the KVM itself does not "always" cause a problem, just on this system.

[mitch (mitch-linux-kernel-bugs)]

Created attachment 18274
Dmesg and USB Registers

Have not run all the tests you asked for yet, but some feedback on the patch:
- Applied the patch.
- Booted with the KBD and Mouse plugged into the ATEN KVM.
- Turned on USB drive (connected direct).
- Got half way through typing the mount command and the keyboard went away.
- Powered off the USB drive.
- Did a dmesg dump and USB register dump (attached).

In addition to running the other requested tests with the unpatched kernel I will try the patched kernel without the ATEN KVM connected.

[stern (stern-linux-kernel-bugs)]

The ohci register dumps are now unnecessary. What we need to see are the files in the ehci/0000:00:13.5/ debug directory (not just the "registers" file, all of them).

[Martin Lubich (mlubich)]

I have to take back, that my system works after increasing the voltage as stated in post 346.

The problem reappeared on my system (no hardware changes, no usb setup changes) first in Intrepid Beta ( using the latest [final?] 2.6.27 kernel ) and soon after on my actual Hardy system.

So I am at the beginning again. Disabling ehci is NOT an option for me, as I do my backups to external drives which involve several GB data volume.

I already considered buying a new motherboard, but reading again through all the posts, I suspect that there is no real guarantee that it will work.

So my last experiment before I take it personally will by to use a pci based usb controller card and see what happens.

This is extremely annoying !

[bettlezap (orjan-nordlund)]

I can verify that the bug exists in Intrepid Beta with the 2.6.27 kernel as well as vanilla kernel 2.6.27.

Running AMD Geode LX800 / CS65535 companion chip, Thecus N2050 Raid array with USB2.0

Same disk(s) works perfectly on both mac osx (10.4) and windows xp

[Mundi Granja (mundigranja)]

I can verify that the bug exists in Intrepid Beta with the 2.6.27-7-generic kernel running in an Acer Aspire 1690.

The USB disk works perfectly in a Debian lenny installed on another partition of the same notebook.

[Tommy Vestermark (tov)]

I can confirm the bug in Hardy kernel 2.6.24-19-generic with an AMD 780G board with SB700 southbridge (A Gigabyte GA-MA78GM-S2H). The bug only appears when using USB mass-storage devices. I have used the following script to recover from the error:
# modprobe -r ehci_hcd
# sleep 1
# modprobe ehci_hcd

I have just tried the following as described above:
# echo -1 > /sys/module/usbcore/parameters/autosuspend
And it seems to make the problem disappear :-)

$ lsusb
Bus 007 Device 002: ID 07cc:0501 Carry Computer Eng., Co., Ltd
Bus 007 Device 001: ID 0000:0000
Bus 006 Device 006: ID 05ac:0221 Apple Computer, Inc.
Bus 006 Device 005: ID 05ac:1006 Apple Computer, Inc. Hub in Apple Aluminum Keyboard
Bus 006 Device 004: ID 046d:c046 Logitech, Inc.
Bus 006 Device 003: ID 03f0:2112 Hewlett-Packard
Bus 006 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
Bus 006 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000

[Kjetil Thuen (kjetil-thuen)]

After having actually upgraded to intrepid (rather than just testing the live cd for a little while), I experienced the bug again today. So I guess I was just lucky when I did not experience the problem with the live cd as I reported in my comment september 6, and the bug is indeed still there in 2.6.27.

[TheBigT (kerecsen-bigfoot)]

Here is another confirmation that things are as horrible as they ever were after an update to Intrepid RC.

[Perry E. Metzger (perry-piermont)]

TheBigT <email address hidden> writes:
> Here is another confirmation that things are as horrible as they ever
> were after an update to Intrepid RC.

Same here. Nothing has changed, and given how little attention has
been paid so far, I doubt this bug will ever be fixed.

[mitch (mitch-linux-kernel-bugs)]

Haven't been able to get to the additional tests yet, but I will soon.

Wanted to add some additional info that I forgot to mention, although it's probably not technical enough to help debug anything: when I boot the Linux systems and hit escape to clear the OpenSuSE splash screen and look at the boot messages there's garbage amongst the messages, eg:

^[^[^[^[^[^[^[^[^[^[^[ Your boot message here...

When I hit a backspace the garbage stops.

Also, I recently added a fourth system to the KVM that has a GeForce 8200 chipset. With this system when I boot and go into the BIOS, quite often the BIOS starts flashing screens/popups rapidly as if it's receiving keyboard input. Sometimes by hitting backspace I can get it to stop, sometimes I can't. Once the system boots it's fine and it also is fine with external USB drives.

I've posted a support request with ATEN. Hopefully, I'll get back to testing it some more this week or next.

[TDB (michael-baranov)]

Intrepid 2.6.27-7-generic falls back automatically and mounts my drive in USB 1.0/1.1 mode when plugged. When booting with the drive plugged in, it's mounted full speed.

[TheBigT (kerecsen-bigfoot)]

I'm simply puzzled by the lack of attention to this bug. One of the fundamental features of the OS is unusable and nobody cares.

To direct some attention, I'm offering a $100 bounty, payable through paypal to anyone willing to fix this (I can also escrow the money to an intermediary if necessary). This sum will clearly not cover the amount of work necessary, but may move this bug up a little in the priority list.

[Troy R. (dsm-iv-tr)]

I'm really quite surprised, too.

Given the workaround is simply to disable USB2 and ergo cause all
transfers over USB to be excruciating slow - costing time & money, you'd
think someone with the knowledge to fix this would have stepped up by
now. Then again, the transfers still -work- at the slower speeds, so
like everyone else I have been satisfied with just waiting the few
minutes more.

I've tried digging around to solve this in my spare time, but I find
myself pretty overwhelmed just trying to learn how the USB subsystem
works despite being quite proficient with C.

I really do like the idea of offering a bounty. If everyone's stuck in
my boat, though, it might not do too much. Just my $0.02.

[Denilson Sá (denilsonsa)]

> Intrepid 2.6.27-7-generic falls back automatically and mounts my
> drive in USB 1.0/1.1 mode when plugged. When booting with the
> drive plugged in, it's mounted full speed.

Just a note: USB 1.x has two speeds: low speed and full speed. USB 2.0 adds another one: high speed.

[Tommy Vestermark (tov)]

OK, the bug just bit me again - even with autosuspend disabled :-( (Hardy, AMD SB700)

It is really disheartening that a bug that renders peoples mouse and keyboard unusable is marked "Won't fix". I have never seen this problem when booting into Windows... so if that is the attitude bug #1 will never be fixed either :-/

I will report later if an upgrade to Intrepid will fix the problem.

[Toby Dickenson (toby-tarind)]

Hi,

A note for those who are dissatisfied with the progress on this bug..... It seems likely that these usb problems could actually be caused by numerous different glitches in different usb controllers or devices. Don't expect one single fix to address all these problems simultaneously; I guess there will only be fixes or workarounds produced one at a time, by someone with access to the relevent hardware.

It is the same situation seen on the release of windows vista, where the minor differences between xp and vista exposed similar device bugs which sent vendors scurrying to produce driver updates.

[Perry E. Metzger (perry-piermont)]

Toby Dickenson <email address hidden> writes:
> A note for those who are dissatisfied with the progress on this bug.....
> It seems likely that these usb problems could actually be caused by
> numerous different glitches in different usb controllers or devices.

No, that's not the issue. The problem is that a deliberate choice was
made to wreck lots of people's USB controllers on the basis that we
weren't important enough to care about.

> Don't expect one single fix to address all these problems
> simultaneously;

NetBSD and FreeBSD deal with these controllers just fine. I happen to
be unfortunate enough to want to run Ubuntu however.

I want to emphasize: this is not some sort of problem that is poorly
understood and caused by buggy hardware. It is well understood and
being ignored.

> It is the same situation seen on the release of windows vista, where the
> minor differences between xp and vista exposed similar device bugs which
> sent vendors scurrying to produce driver updates.

That's not even a remotely apt analogy. Among other things, this bug
has been around since before the release of Vista and no one intends
to fix it.

Perry
--
Perry E. Metzger <email address hidden>

[Josh Rhoderick (rhoderickj)]

Open source EPIC FAIL.

[JustinGosselin (justin-gosselin)]

adding acpi=noirq to grub kernel options corrected all ehci_hcd problems for me. Works in Ibex too. Anyone else doing this?

[Heiko M. (hmeyer-cakesoft)]

if have the same problem. I use the following hardware:
USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)

The only thing helps is to disable the USB 2.0 (BIOS) or to set the kernel option acpi=off (the others don't work).

[AlfonSkunk (alfonskunk)]

Ok!

Suddenly all works o n Intrepid Ibex and kernel 2.6.27-7

With the same kernel and conf, yesterday didn't work... I'll looking for changes... Maybe Obama?? XD

I'll post soon!

[mitch (mitch-linux-kernel-bugs)]

Created attachment 18766
dmesg and usb register dumps

Tested four configurations with kernel 2.6.27.5:

1 - With ATEN KVM. Fails as before: can't complete write to USB HD
    and keyboard communication is lost. (dump withkvm)

2 - ATEN KVM unplugged. KBD and USB HD plugged into a DLink hub.
    This *fails* also: can't complete write to USB HD and keyboard
    communication is lost. (dump withdlink)

3 - ATEN KVM unplugged. KBD plugged into DLink hub, HD plugged into MBD.
    This works but it looks like (if I'm understanding the log messages)
    that it was still losing communications with the keyboard, although
    the keyboard continued to work. (dump withdlink-kbd)

4 - ATEN KVM unplugged. KBD plugged MBD, HD plugged into DLink hub.
    This works: write completes, KBD continues to work. (dump withdlink-hd)

Note that the garbage output characters during boot seem to have gone away with the new kernel.

[David Morgado (dcrmorgado)]

Hi,
I also have this problem on my laptop, a TOSHIBA Satellite A300D model (PSAK8E-001003PT).
I'm using the latest release of ubuntu 8.10 amd64 with the latest patches as of today.

Some of the solutions pointed here worked from time to time but not always, there where times that the defaults actually worked. Funny thing...

Anyway, my webcam (integrated with the laptop) and my wireless card are usb 2.0 so having ehci-hcd removed is not a option, actually the wireless card (realtek 8187b integrated) works in usb 1.0 mode but the webcam is a no go.

I managed to trace the problem back to the webcam module, uvcvideo, by trial and error blacklisting those usb device modules one at the time in several combinations.

So there is a conflict with the integrated usb webcam module (uvcvideo) on my laptop and something else that interferes with the ehci module, blacklisting the uvcvideo module and everything works fine them, wireless and usb pendrives.

More, if after this, II manully modprobe for uvcvideo after boot on the gnome desktop everything keeps working fine webcam included.

One more thing offtopic, not intirely usb related, on this laptop I have to use acpi_osi="Linux" boot option otherwise this thing keeps rebooting on halt instead of powering off, and complains about an "irq 9: nobody cared".

I attached a few ls* and dmesg for this laptop for you viewing pleasure ;).

Thanks

[Heiko M. (hmeyer-cakesoft)]

Hi,

i have test a new USB 2.0 PCI card with NEC- chip set and it worked without acpi=off. So this solved the problem for me.

The onboard chip set ATI SB600 do not work without kernel option acpi=off

Heiko

[lak0 (lak0)]

Hello,

My issue has been solved with this "trick" taken from https://bugs.launchpad.net/ubuntu/+source/udev/+bug/221983

[Perry E. Metzger (perry-piermont)]

ph3ar <email address hidden> writes:
> My issue has been solved with this "trick" taken from
> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/221983
>
> ** Attachment added: "usb_no_key_bug?"
> http://launchpadlibrarian.net/19579922/usb_no_key_bug%3F

This looks utterly unrelated to the problem most people have had in
which specifically USB 2.0 devices fail and a driver downgrade makes
them work.

Perry

[stern (stern-linux-kernel-bugs)]

Your conclusions look right. And they would explain the disk problems: Many EHCI controllers have a bug which causes them to temporarily drop data on one port when a device on a different port disconnects. I'd say that whatever is causing the keyboard communications to drop out manages, every so often, to interfere with the disk traffic.

The computer then tries to reset the disk drive, but many USB drives have a bug which prevents them from resetting correctly when they're in the middle of an I/O operation. As a result, the drive becomes unusable and the system puts it offline.

As for what causes the keyboard problems... I don't know. It could simply be a cabling issue. For example, I've got a USB-to-PS/2 keyboard+mouse converter. It doesn't work at all when plugged directly into my computer, but it works just fine when connected through a USB extension cable. Try and figure that one out!

You could try using a different keyboard. Maybe it wouldn't get all those communications dropouts when plugged into the DLink hub or the ATEN switch.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

As a general note, the parts attached to linux-source-* are irrelevant - the kernel has changed source package name, so the statuses under 'linux' are the ones to watch for.

As for why this has apparently had no kernel team attention, i've no idea...

[Tobias Brandt (tobiasbrandt)]

I had the same problem with my WD MyBook EssentialEdition 320GB. I could solve it with the following command:

echo "128" > /sys/block/sda/device/max_sectors

where /dev/sda is the device in question. I haven't had a disconnect for a few weeks now. I'm (still) on Ubuntu Gutsy, 2.6.22-14-generic.

[gryffus (gryffus-linux-kernel-bugs)]

Hello! I have same issue since todays upgrade... What should i do to properly report?
Only connected device is USB logitech G5 mouse...
It is KT400 chipset.
I have tried unloading and reloading uhci_hcd, ehci_hcd and ohci_hcd modules with no difference...
The mouse first turns on and after few seconds it turns off... When i run lsusb it again tries to turn on, but without sucess...
My OS is openSUSE factory (development version) and i have tried 2.6.26 and 2.6.27 kernels...

dmesg:
device descriptor read/64, error -62
device descriptor read/64, error -62
new full speed USB device using ohci_hcd and address 3
device descriptor read/64, error -62
device descriptor read/64, error -62
new full speed USB device using ohci_hcd and address 4
device not accepting address 4, error -62
new full speed USB device using ohci_hcd and address 5
device not accepting address 5, error -62

lsusb (with connected mouse):
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[stern (stern-linux-kernel-bugs)]

Your mouse isn't working at all. This is a very different problem from the other problems in this bug report; you should not have posted it here.

Either your mouse is broken or else your computer's OHCI controller is broken.

[Troy James Sobotka (troy-sobotka)]

Any progress on this?

It seems that highspeed transfers here work fine up to around 500 megs. Stuffing more in the queue gags ehci_hcd and forces a reload. Transferring pictures 20 or so 15 meg files at a time is nauseating though. To this end, it would see tied to Tobias Brandt's comment https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372

Regressions are something we as a community _really_ need to sort out.

The impact of this bug on our audience is tremendous.

[David Morgado (dcrmorgado)]

Well I have found a definitive solution / workaround for this.

As I found out the most recent fedora 10 (tested i386 livecd) release I noticed that the ehci-hcd was compiled in kernel and not as module. Surprise it works flawlessly.

So I recompiled the ubuntu intrepid kernel 2.6.27-9.19 amd64 generic with CONFIG_USB_EHCI_HCD=y and CONFIG_USB=y (required to have ehci in kernel) and now everything works as it should. No errors no disconnects no nothing everything is perfect. Was this the solution for this same problem from the fedora people? I have no idea. Please check if possible.

So I have a request, is it possible to have the official intrepid and hardy kernels have ehci-hcd built in the kernel and not as module?

Thanks
David Morgado

[David Morgado (dcrmorgado)]

Definitive for me at least, sorry. If the affected people here have the knowledge of how to recompile the kernel please do so and report back. I have debs for amd64 arch if anyone wants to test them please say so.

Thanks
David Morgado

[David Morgado (dcrmorgado)]

Ok, disregard those last two posts, damm thing still happening It just didn't at first boot with new kernel. WTF????

Thanks
David Morgado

[Denilson Sá (denilsonsa)]

On Mon, Dec 1, 2008 at 21:06, David Morgado <email address hidden> wrote:
> Ok, disregard those last two posts, damm thing still happening It just
> didn't at first boot with new kernel. WTF????

I was expecting that.

I had this problem years ago, with USB modules built-in. Then, I've
chosen to compile them as modules to make it possible to unload (and
reload) ehci.

This is a kernel issue, it does not affect only ubuntu, but all
distros. Also, it only affects certain types of hardware (probably,
host controller is the key here), while doesn't affect others.

--
Denilson Figueiredo de Sá
Vialink / Dream Solutions
Rio de Janeiro - Brasil

/"\
\ / ASCII Ribbon Campaign
 X against HTML e-mail
/ \

[AntoninoArcudi (antonino-arcudi)]

I have the same problem and some problems with built-in device of my laptop Aspire 5602 4.024114] usb

usb 2-2: device not accepting address 2, error -71
usb 5-6: new high speed USB device using ehci_hcd and address 3
usb 5-6: configuration #1 chosen from 1 choice
usb 5-6: USB disconnect, address 3
usb 5-6: new high speed USB device using ehci_hcd and address 4
usb 3-2: new full speed USB device using uhci_hcd and address 2
usb 3-2: device descriptor read/64, error -71

lsusb
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 009: ID 0f62:1001 Acrox Technologies Co., Ltd Targus Mini Trackball Optical Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

[AntoninoArcudi (antonino-arcudi)]

i forgot:
intrepid ibex
Linux Pearl 2.6.27-10-generic

[archdrone (archdrone)]

AntoninoArcudi: I think you have spotted different bug. Your bug prevents USB device from being recognized correctly and such device on your system cannot be mounted. But this "ehci_hcd or usb_storage I/O errors bug" is different. You can mount a USB device but after some time and when star constellation is wrong no-sense errors and ehci-reset errors appear and then the USB device is not functional.

[archdrone (archdrone)]

oops, im in wrong ehci-hcd bug thread, sorry

[AntoninoArcudi (antonino-arcudi)]

Thanks archdrone, i have to move o delete my report? i don't want to generate chaos

[archdrone (archdrone)]

AntoninoArcudi: "oops, im in wrong ehci-hcd bug thread, sorry" :) I thought I was in #264789 "USB Hard Drive Not Accessible, vol_id hangs" thread. That bug happens also because of ehci_hcd module which causes I/O errors and ehci resets. Please ignore me and I'm sorry again:)

[zasq (zasq)]

Hi,
have the same problem (intrepid, 2.6.27-9-generic kernel), but as I'm no expert, I'm scared to recompile the kernel as David Morgado suggests. Does someone know if the problem will be fixed soon?

lsusb:
Bus 006 Device 006: ID 03f0:5511 Hewlett-Packard Deskjet F300 series
Bus 006 Device 005: ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX
Bus 006 Device 003: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 1058:0702 Western Digital Technologies, Inc. Passport External HDD
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The printer for example isn't recognized right now, even though it is in the list. So I have to restart the laptop (Dell Inspiron 1501) very often to make my devices (also external HDD) work...

[Perry E. Metzger (perry-piermont)]

zasq <email address hidden> writes:
> Does someone know if the problem will be fixed soon?

I don't know for sure, but my strong suspicion is that no one who is
in a position to fix the problem has any intention of ever working on
it. This report has been open for a long time and nothing much has
happened. I see no reason to believe a fix will ever happen.

A non-charitable reading would be that apathy has taken hold. A
charitable one (which I think might be more accurate) is that
Canonical is resource limited and is now far beyond its capacity to
cope with bug reports, which become more numerous as the popularity of
Ubuntu grows. I would, of course, be very pleased to be proven wrong,
but I fear I won't be.

As it stands, my Ubuntu laptop, which worked fine a few releases ago,
is suffering from multiple crippling bugs, all of which have long
standing open bug reports confirmed by multiple sources, all of which
have been ignored much like this one.

I can no longer use it terribly effectively -- USB is failing, my
wireless card will not recover from sleep without a reboot and stops
working for several seconds every couple of minutes, etc -- and I'm
soon going to to have to abandon Ubuntu in order to be able to use my
laptop again.

It is a great shame, but it appears that, as it stands, Ubuntu is
slowly falling apart, apparently because its popularity has strained
the limited support resources beyond the breaking point. Perhaps this
is a lesson in how a distribution like this can or cannot be managed
in a scalable fashion.

Perry

[Troy R. (dsm-iv-tr)]

Perry's story breaks my heart. :\

I think having the tenacity to see this problem through (much like other
problems Ubuntu has had) will likely benefit us all more in the long
run. Please, Perry, continue to use your laptop install if you can and
help us test new solutions as they arise. Please? :)

That said, I've tried the latest upstream kernel and end up with the
same bug.

I suspect very strongly this isn't an "ubuntu" bug as much as it is a
chipset-related one, but I guess I have little evidence beyond
correlations...

[MountainX (dave-mountain)]

I have the nVidia chipset in an Asus A8N5X motherboard. I had to turn off USB 2.0 support in the bios to work around this bug.

Since it does not sound like a resolution for this bug is to be expected soon, I think I will purchase a new motherboard. How can I find out which motherboards will *not* have this problem? Thank you.

[Josh Rhoderick (rhoderickj)]

I know we're not supposed to use this as a forum for discussion, but this bug has me frustrated beyond belief. I agree with Perry's assessment of the problem. My situation is similar: I stopped using Ubuntu at Hardy because of these unresolved bugs (of which this bug is only one of the many that made my computer unstable and unusable). I've since purchased a Macbook and I have no plans to go back to Ubuntu full-time. I think this bug is a perfect example of FOSS's limitations: if there is no financial motivation to keep end-users up and running, then why put in the hard work to resolve difficult bugs like this one? In short, no one cares if our systems don't work, and that is unacceptable to me. I'm remaining a subscriber to this only to see if anything is done about it.

[Troy James Sobotka (troy-sobotka)]

I'll thank Robert North here... his post regarding autosuspend seemed to work for me. Tested using a few gigs worth of raw photos.

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209

[Troy James Sobotka (troy-sobotka)]

Addendum to above post - the problem still persists but appears to have gotten slightly better. I can transfer more before ehci_hcd fails. This is unfortunate.

I am wondering if there is anything we can do collectively to help this along?

[Tobias Brandt (tobiasbrandt)]

Did you try this:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372

It still works for me after more than a month.

[Perry E. Metzger (perry-piermont)]

Troy James Sobotka <email address hidden> writes:
> I am wondering if there is anything we can do collectively to help this
> along?

I think no one is looking at it. The first step would have to be to
get someone at Canonical to pay active attention to the problem and
take responsibility for having it fixed. Until then there is no
point.

Perry

[Andy Whitcroft (apw)]

Right now there is no upstream bug open for this issue, so its not going
to get any community focus. The bug currently linked was closed after the
reporter indicated a replacement hardware unit made the issue go away.
If this is still occuring for a number of you, then a new bug should be
files upstream too. It does seem to affect more than one distro so I
assume it really is an upstream regressions.

Reading the epic that this bug has become its not clear who has tried
which of the workarounds. It would be helpful to have a clear answer
from those who have this bug whether the work around in comment 209
works for them or not:

  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209

Also from the fedora bug it appears that reordering the driver loads for
the usb drivers made a difference. It might be interesting to try
blacklisting uhci-hcd to see if that helps at all; that is adding
blacklist uhci-hcd to /etc/modprobe.d/blacklist.

[phaidros (phaidros)]

Andy Whitcroft wrote 58 minutes ago:
> Also from the fedora bug it appears that reordering the driver loads for
> the usb drivers made a difference. It might be interesting to try
> blacklisting uhci-hcd to see if that helps at all; that is adding
> blacklist uhci-hcd to /etc/modprobe.d/blacklist.

Thanks Andy! You saved my day. Blacklisting uhci-hcd seems to solve the issue for me.
At least I can confirm, that all usb sticks and card readers which refused to get detected before are working now, even when adding a bunch of 5 of them via usb hub. Great!

Folks, consider try blacklisting uhci-hcd and report back. It *might* be the help :)

[Denilson Sá (denilsonsa)]

On Sun, Dec 7, 2008 at 22:59, phaidros <email address hidden> wrote:

> Folks, consider try blacklisting uhci-hcd and report back. It *might* be
> the help :)

I'm really not sure, but... isn't uhci/ohci required for
low-speed/full-speed devices? Or for USB 1.x devices? (even when
connected to a USB 2.0 host) I might be completely wrong, though.
Could someone please clarify?

[Troy James Sobotka (troy-sobotka)]

As per Andy Whitcroft's suggestions:

1) Attempted the usb-core-options modification as per https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/209 with _no_ success in the end.

2) Attempted to adjust max_sectors as per https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372 and inevitably was _successful_. It had to be done each time the device was hot plugged however. To locate the device, perform a 'sudo fdisk -l' to list the device and then 'sudo -s' and perform the 'echo "128" >' to the proper device as per the link. High speed transfers worked as expected. Tested twice with slightly over a gig of raw photos.

It should be noted that the 'fix' to remove ehci_hcd is not a fix unless you find low speed one meg per second transfer speeds acceptable.

Q: Is there a way to automate the 'echo "128" >' command to the hot plug devices to avoid having to manually do this each time the device is attached?

<Editorial Alert>
Finally, I'd add that those who are disillusioned with Free Software need to examine their own perspective on the matter. Remember -- Free Software isn't a 'them / they / other' scenario. With the exception of vendor specific proprietary issues, if Free Software fails we have no one but ourselves to blame. The path we choose isn't an easy one. Such is the price of Freedom.
</Editorial Alert>

Thanks to Andy Whitcroft and Tobias Brandt for suggesting the workaround in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372.

[Andy Rabagliati (andyr)]

I have a brand new machine, with Intrepid installed on it. My hardware combination triggers this bug.

After reading this thread, and many others similar to it, I have narrowed my problem down to the boot time interaction of ehci_hcd and my Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer.

* Linux boxrd 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux
* rmmod ehci_hcd -- works
* kernel recompile with USB non-modularised -- doesn't work (was suggested elsewhere)
* echo 64 > /sys/block/sdh/queue/max_sectors_kb -- doesn't work (and 120 also doesn't work)
* rmmod uhci_hcd -- Doesn't work (besides disabling my USB keyboard - suggested elsewhere)
* Unplug Bus 004 Device 002: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer -- works
* Plug in Bus 004 Device 002: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer after boot -- works

Logs attached - lspci-vvnn.log, lsusb.log (including Alcor), dmesg.log (doesn't work) dmesg2.log (works)

[Perry E. Metzger (perry-piermont)]

Troy James Sobotka <email address hidden> writes:
> <Editorial Alert>
> Finally, I'd add that those who are disillusioned with Free Software

I'm not disillusioned with free software. I'm being forced to switch
from Ubuntu. There is a difference between being disillusioned with
free software and having your laptop unable to work as a result of
software upgrades, forcing you to switch to another OS.

Perry

[MountainX (dave-mountain)]

Pardon me for asking my question a second time. I appreciate anyone pointing me to a source of info that will tell me which hardware is NOT subject to this bug. I'm willing to change hardware to keep Ubuntu.

My problem sounds identical to Andy Rabagliati's. For example, I see endlessly repeating messages like this:

[ 19.080009] usb 5-3: reset high speed USB device using ehci_hcd and address 4
[ 19.336509] usb 5-3: reset high speed USB device using ehci_hcd and address 4
[ 19.592009] usb 5-3: reset high speed USB device using ehci_hcd and address 4
[ 19.840009] usb 5-3: reset high speed USB device using ehci_hcd and address 4
[ 20.088009] usb 5-3: reset high speed USB device using ehci_hcd and address 4

Which chipsets are safe to use with Ubuntu to avoid this problem? Thanks.

[Andy Rabagliati (andyr)]

MountainX, do you have any USB 1.X devices plugged in, like my card reader ? Can you live without them ? What does lsusb say ?

[Denilson Sá (denilsonsa)]

On Mon, 08 Dec 2008 14:31:26 -0200, MountainX <email address hidden> wrote:

> Pardon me for asking my question a second time. I appreciate anyone
> pointing me to a source of info that will tell me which hardware is NOT
> subject to this bug. I'm willing to change hardware to keep Ubuntu.

My laptop has Intel chipset: Intel Corporation 82801H (ICH8 Family)
I don't have this bug on my laptop.

My (quite old) desktop has a Via USB 1.1 on-board controller and one ALi
USB 1.1/2.0 PCI controller.
I have this bug on my desktop.

Also, as told many times, this bug is not exclusive to ubuntu, it is a
kernel issue.

[MountainX (dave-mountain)]

Thanks CrazyTerabyte and Andy Rabagliati.

>What does lsusb say ?

lsusb
Bus 001 Device 005: ID 0aec:3260 Neodio Technologies Corp. 7-in-1 Card Reader
Bus 001 Device 004: ID 0b33:0700 Contour Design, Inc.
Bus 001 Device 003: ID 05f3:0203 PI Engineering, Inc.
Bus 001 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 001 Device 001: ID 0000:0000

I don't know what Bus 001 Device 001 is.
I could certainly change brands for my card reader (Device 005).
The other devices are all required for input (they are my mouse, keyboard).

From reading past messages on this bug, I was under the impression that this problem is commonly seen the nVidia chipset found in my Asus A8N5X motherboard. That's why I thought changing motherboards would be the appropriate solution...

Thanks for the help!

[Troy James Sobotka (troy-sobotka)]

While not limited strictly to Alcor, it appears many problems lie with this chipset. My chipset is an Alcor (nGear multi card reader / hub) as is the official bug report at kernel.org:

http://bugzilla.kernel.org/show_bug.cgi?id=ehci_hcd
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/62
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/119
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/299
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/397

I will suggest to anyone with an Alcor to attempt the above workaround as listed in comment https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/372

To help out the developers it might be prudent to identify the offending chipsets that are misbehaving.

[Tim Penhey (thumper)]

After quite a but of hunting and messing around, I found out the source of at least my problem.

I have a Sony Vaio SZ2XP using a VSP-MCA20 express card to read SD cards. This card reader does not read SDHC cards, and searches on various Sony websites leads me to believe that it never will.

It also seems that my other card readers also do not handle SDHC cards either. I'll probably go and buy a newer card reader and most likely buy a Dell for my next laptop.

[David Becker (becker-david)]

SNAFU

I've installed Fedora 10 Live CD to USB flash media.

Installed the i686 as well as the x86_64 version.

Installed on an nforce 430 platform and an SB600.

Installed to Kingston and Sandisk USB drives and to Sandisk SD card.

Every combination here is botched.

Decreasing max_sectors seems to alleviate the problem, but likely only because the probability of some timing error is decreased in that way.

Changing autosuspend and level parameters (in /sys/devices/pci.../*usb*/power/) also alleviates the problem, but doesn't resolve it.

When starting up, the Kingston (USB drive) media has it's power level set to "on". The EHCI host controller it's attached to however has it's power level set to "auto".

I've changed all power levels to "on" (also for the OHCI controllers). Although superfluous, I've set all 'autosuspend' values to -1. I've set the flash media's max_sectors to as low as 32, but have also extensively tried 128 and the default 240 (who came up with this value. Someone who watched the new time tunnel pilot?).

Booting the USB media, then running something like 'yum update' eventually generates an error akin to "unable to flush to dm-0" and then the dreaded "I/O Error, lost page write".

FWIW, "badblocks -w [drive]" reports no errors.

SB600 (laptop) is running on AC power. (nforce is a desktop).

Just the error (and a reboot) would mean a bug.

The fact that the entire system is deterministically non-bootable (I don't even want to attempt to salvage it) after these errors are reason for me to qualify this as a serious bug.

David

[Andy Rabagliati (andyr)]

David, please attach lspci -vvnn and lsusb. Do you have an Alcor chipset ? can you unplug it and try again ?

[David Becker (becker-david)]

I don't believe this an Alcor chipset. Bear in mind it occurs with an SB600 (AMD/ATI) and nForce based system.

Following lspci/lsusb output is when running the system from harddisk (I'll see if there's a 'diff' between booting from flash and (normal) hard disk booting).

David

[David Becker (becker-david)]

Whoops, the previous 'lsusb -v' is secretly just an 'lsusb'.

Here's the verbose version.

[David Becker (becker-david)]

BTW, aforementioned output for lspci and lsusb is for the SB600 (laptop) based system. No USB flash media was attached. I've included the output for 'lsusb -v' once again, only now with the (Kingston) USB media attached. I can't reach the other (nforce based) system at the moment, but...

... the 'No power switching' as well as the '0 milli Ampere' on every hub has got me frightened.

Maybe the devices are underpowered? I'm logged into other systems (MSI motherboard, HP Proliant) which show:

Per-port power switching
bHubContrCurrent 100 milli Ampere

I'll try it on the MSI (K9A2 CF motherboard iirc) later on.

David

[David Becker (becker-david)]

Maybe it's better to skip that MSI board.

One of the first things I noticed was "Genesys Logic".

Didn't various species go to war over Genes(i|y)s in Star Trek movies? Christopher Lloyd described it as "The Genesis Torpedo".

Anyway, max_sectors was 240 for the flash device. I set that to 64, then proceeded with the usual 'yum update'.

It didn't even allow me to start downloading. I got a "Hub disconnect" message and that was pretty much it. The errors are actually different from the previous errors. I'm seeing all kinds of FAT errors and I can't say I noticed the "lost page write" errors, so there's presumably something else wrong with this system (Genesys?).

The (Kingston) flash device was attached to a USB port on the back of the system.

I'll see if I can try it on the Proliant tomorrow, but they take so long to start up. FWIW, I've attached the lsusb output for this system.

David

[Peter Hoeg (peterhoeg)]

Something just struck me. This error was happening with a previous laptop, but neither my current laptop nor current desktop.

I had an external LaCie HDD, which when formatted with VFAT would show this kind of behaviour but was working fine with EXT2. I know that offhand it doesn't sound like it makes a lot of sense assuming the error is in the USB level code, but can one of you people who can reliably reproduce the error, give it a go with EXT2?

[Troy James Sobotka (troy-sobotka)]

Well well well... Good spot Peter Hoeg.

I formatted my 8 gig 133x digital still camera compact flash to ext3. I tested with pushing a gig to it and then pulling the gig back.

Thus far, no errors.

As a result, the previous VFat32 might be the cause of the problem?

[Peter Hoeg (peterhoeg)]

I have nowhere near enough knowledge of the linux kernel to make any kind of qualified statement on this - it is however, not going to stop me from doing it anyway...

I see two possible reasons:

a) An actual vfat error (linux's vfat code)
b) Due to different usage patterns, the vfat usage triggers a (timing?) error in the USB code

I am hoping that somebody with more technical insight can shed some light on this.

Can somebody else try with ext2/3 ? I can't myself, as I have no machines affected by this.

[Troy James Sobotka (troy-sobotka)]

Bad luck. Retested with ext2 and it bombs out with several input / output errors and then finally crashing ehci_hcd.

I should note that this appears to happen only when writing from the device to disk. Disk to device appeared to go normally except it couldn't be unmounted gracefully.

I suppose the net conclusion on this is that different filesystems _appear_ to exhibit different behavior that still ultimately results with the well known ehci_hcd bombing out. VFat32 is certainly ungraceful. ext3 needs to be tested further. ext2 offers up input / output errors and then ungraceful bomb.

[Andy Rabagliati (andyr)]

I have a feeling there are two different bugs here. All these filesystem comments, and "echo 64 > /sys/block/sdh/queue/max_sectors_kb" make no sense to me, as often the device (/dev/sdh or whatever) has not even come up.

I tried formatting my USB stick as ext2 - but it makes no difference.

As mentioned earlier, *my* bug is a boot-time interaction between ehci_hcd and my Alcor Micro Corp card reader - I think the only USB 1.X peripheral.

I have tried a PCI addin card with two USB ports - ( ALi Corporation USB 1.1 Controller // ALi Corporation USB 2.0 Controller ) - an old piece of hardware that works fine elsewhere - drives don't work there either if the Alcor card-reader is plugged in.

It could be an interaction between the Alcor and the Intel Corporation 82801G (ICH7 Family) USB UHCI Controller - it has a 9 pin header that I can't plug into the Ali Corp card.

My solution is simply to unplug the Card reader - if I need it I can plug it in after boot. Everything works fine then.

I have tried loading the USB modules in a different order - it makes no difference.

[Troy James Sobotka (troy-sobotka)]

@Andy Rabagliati: Absolutely. I have had that bug / regression before. It most certainly is a mounting problem. It _may_ indeed be related to whatever underlying chipset Alcor is using as I suspect the Alcor is ultimately just junk. What would be interesting is to somehow get a feeling for what underlying hardware is being used at the chipset level in these devices.

I'd suggest you track down the appropriate bug report and report if necessary. It might be wise to reference this bug report as I find it suspect that your card reader also happens to be an Alcor.

I did a further test with the digital SLR camera itself and it mounts fine and transfers files 100% properly and speedily with _no_ problems. This gives further credibility to the notion that the crashing of ehci_hcd is directly related to particular hardware of the actual devices -- not the host bus controller / combination.

I'd certainly be willing to flag Alcor as a hideous vendor (included in nGear, NMedia, and other models.) If David Becker's bug is related as it appears to be (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/409) it would seem that we could add Kingston to that list at least in one instance.

What we somehow need to do is:
1) Identify exactly what underlying hardware is the source of the problem in the devices.
2) Provide a way for people who are stuck with onboard card readers of the hardware to have the 'echo "128" >' command automatically done every boot for them.
3) Figure out who we need to contact regarding the bug. Greg Kroah-Hartman suggests at the end of http://bugzilla.kernel.org/show_bug.cgi?id=ehci_hcd to file it to the linux-usb list. I'm not entirely sure that it belongs there though?

Good detective work folks. I think we need someone to help us figure out the lower level stuffs on the devices somewhere? Perhaps the only way is through documentation? Is there a way to read more deeply into the device's ancestry?

[zasq (zasq)]

Hi guys,
I'm no expert on this either and a little confused by now. I have the problem (as mentioned above) on a Dell Inspiron 1501 AMD Turion 64 with ATI SB600 Non-Raid-5 SATA chipset (if I read the device manager correctly). Nothing with "Alcor" in it, right? The bug - that means crashing/ejecting usb-devices with a I/O error happens with several devices: My HP DJ F380 Printer, my WD Passport External HDD (which is formatted with ext3 and still crashes, as mentioned by Troy, when copying from the external drive to disk). It primarily happens when writing bigger files or high speed is required. For example, I can't burn a dvd with data from the external drive. And the printer crashes when scanning or printing big files. I always need to restart the whole system. I would like to help with this matter, if you would like me to upload any logfiles please tell me which ones...
Thanks for all your work - I'll stay with ubuntu :)
zasq

[Troy R. (dsm-iv-tr)]

My hardware is near-identifcal to zasq's; same bug.

lspci attached.

[David Becker (becker-david)]

I also think there's two bugs going on here.

Note however, I also use a WD Passport (320GB) drive (on the SB600, the nforce, the MSI and Proliants) and never have had this problem. I transfer large (and many) files to and from the Passport drive and USB flash media with no problems. It's only with the (Fedora) livecd, so I'm now guessing that my problem is somewhat different than what's going on here.

I'm preparing an Ubuntu livecd on USB at the moment. Seems like it works more-or-less the same as with Fedora, that is, underlying (generic FAT) filesystem, squashfs base image and some form of overlay for persistence, although with Ubuntu there's a separate ext3 (casper-rw) filesystem while Fedora (apparently) stores it's persistence data in an (loop back mounted) LVM copy-on-write snapshot. So many choices ;-)

Sorry for the confusion/contamination,

David

[Troy James Sobotka (troy-sobotka)]

@zasq and Troy R.:
Chances are that there could be either the same underlying chip / hardware at the core of the Kingston. Alcor is just the identifier, and is certainly a vendor that will exhibit this bug. There are probably more. The key here is to locate the USB vendor so we can provide a list. I have seen the Kingston show up on someone's pendrive in this list, and as such, I'd say that so far it is consistent with our other findings.

The big boggle here is that David Becker's drive doesn't exhibit this behavior. It is quite likely and probable that the underlying chip / board in the drive is _different_ from the chip / board in your drives. This is common and is also seen in wireless cards where in spite of an identical model and brand, the chipset _may_ be different based on sub versions.

I'd compile a list of the suspect boards if we can separate the bug into those that are actually mounting but failing. For example, mine look like this after an 'lsusb':

ID 058f:6366 Alcor Micro Corp.
ID 058f:6254 Alcor Micro Corp.

The above fix will work that is noted in the bug report. Locate your drive location path and perform the 'echo "128" >' etc. line.

As for the mounting problem, I can't seem to find the appropriate bug report.

Hope this helps. For those with devices that _mount_ but gag out and crash ehci_hcd after transferring, please state such and locate the appropriate device ID in your lsusb output. Maybe that will help a dev / hacker locate the problem. I'll donate my card reader to the cause...

[Oisín Mac Fhearaí (denpashogai)]

2008/12/11 Troy James Sobotka <email address hidden>:
> I'd compile a list of the suspect boards if we can separate the bug into
> those that are actually mounting but failing. For example, mine look
> like this after an 'lsusb':
>
> ID 058f:6366 Alcor Micro Corp.
> ID 058f:6254 Alcor Micro Corp.
>
> The above fix will work that is noted in the bug report. Locate your
> drive location path and perform the 'echo "128" >' etc. line.

Everybody seems to be assuming lately that this bug only affects USB
storage devices. However, I was getting these errors with a USB
wireless adapter and I'm sure other people on this buglist are not
only having trouble with storage devices. I say this because the focus
of comments recently seems to be shifting towards the assumption that
only drives are affected and how to mask/avoid that problem.

Oisín

[Denilson Sá (denilsonsa)]

On Thu, 11 Dec 2008 10:52:00 -0200, Oisín Mac Fhearaí
<email address hidden> wrote:

> Everybody seems to be assuming lately that this bug only affects USB
> storage devices. However, I was getting these errors with a USB
> wireless adapter and I'm sure other people on this buglist are not
> only having trouble with storage devices. I say this because the focus
> of comments recently seems to be shifting towards the assumption that
> only drives are affected and how to mask/avoid that problem.

True. zasq said yesterday that his printer/scanner also crashes.

I think the issue is related to host controllers (a small card reader and
an external HD reader both showed problems in my desktop, and I guess any
device I put there will have problems; but I don't think I have any
problems in my laptop).

Maybe there are two or more bugs, but I think at least one of them is
related to host controller.

[Troy R. (dsm-iv-tr)]

> Hope this helps. For those with devices that _mount_ but gag out and
> crash ehci_hcd after transferring, please state such and locate the
> appropriate device ID in your lsusb output. Maybe that will help a dev
> / hacker locate the problem. I'll donate my card reader to the cause...

@Troy S.:
Sure thing. This is the relevant lsusb line for my controller, on an ATI
SB600 mobile board:

Bus 004 Device 002: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub /
D-Link DUB-H4 USB 2.0 Hub

With ehci_hcd loaded, devices _mount, but choke out even after applying
the max_sectors tweak_. I then have to blacklist ehci_hcd and reboot to
restore USB 1 functionality.

Offhand, I believe we've seen this "Genesys" name before, earlier in the
thread.

Full lsusb output attached, just in case.

[Troy R. (dsm-iv-tr)]

Sorry; here are both relevant lines from lsusb, to save someone opening
the .log file:

Bus 003 Device 002: ID 05e3:0605 Genesys Logic, Inc. USB 2.0 Hub [ednet]
Bus 004 Device 002: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub /
D-Link DUB-H4 USB 2.0 Hub

Cheers, let's keep working at this!

[zasq (zasq)]

Hi friends,

it really seems hard to really track down the problem. I tried out quite a few tricks and tweaks out of several forums but unfortunately never really took the time to test the single changes and sort out what helped and what didn't. Let's see what I can remember:

1. The USB-connections on my laptop never were perfect, not with feisty, gutsy nor hardy. And not with intrepid. I am very sure that it has to do with the chipset. I don't know how to find out if my ATI-chipset in fact is an Alcor-chipset as Troy J suggests. But I remember that - when I got my Dell almost 2 years ago - I also had the problem with windows vista (I still have a dualboot system, but don't use windows anymore). Back then, Dell sent me some patches for the USB-connections and - strange thing - after applying them, the usb-devices that didn't mount before, could be used in BOTH windows and Ubuntu. The memory-stick worked fine, the printer (which had to deal with bigger files) was always buggy. (I didn't have the WD Ext. HD back then). Half a year ago I did a complete reinstall without those Dell-patches, but everything still worked fine. Maybe the patches had to do with the BIOS and are therefore still "active".

2. Some weeks ago I updated my bios to 2.6.3. I think (but am not sure if it is because of this updating) that after that the mounting of the devices was less buggy. The initial mounting (plug and play) at least works fine now. I also applied the "autosuspend" -1 trick mentioned above by Andrew. That reminds me that I read somewhere that the problem of sudden crashes or self-unmounting (or whatever you would call that) of usb-devices could also have to do with the power management.... As I am no expert in these things, in the past I didn't put attention to the I/O error messages and didn't know about ehci, so I can't say what changed there. Sorry!

3. As mentioned, now the problem remains that all the devices crash once in a while when confronted with big transfer loads. In that case I have to restart the system. It has also happened that I plugged a device in again after a long time (with no restart inbetween) and it would mount again normally. But usually I can't wait for long minutes or hours, so I restart the system.

4. If you take a look at my lsusb and lsusb -vv output (see attached file), there are six usb-devices listed. Nevertheless, the laptop only has four usb-ports (two in the back being Bus003 and Bus004 and two on the right lateral being Bus002 upper port and Bus001 lower port). All these should be USB 2.0 ports but all are filed as 1.1 ports. I have no idea what the other two ports are (one of them being listed as 2.0)!!! As the ports are already listed as USB 1.1 the "echo 128"-thing wouldn't make sense, right? The question is how I can get the ports to be recognized as USB 2.0!

Please let me know what information I can provide to help solve the problem. And remember: I'm no computer expert :)

All the best,

Saskia

[zasq (zasq)]

Oh-oh! I think I don't really understand what the numbers (bus/device) mean in the lsusb-output... The attachment in my last comment was without the devices connected, now I attach the output with the plugged-in devices... Hope this helps...

[zasq (zasq)]

Okay, back from work again.
Sorry for the strange things I wrote/asked above. I now read a little into "ehci", "ohci" etc. in Wikipedia to understand a little better. And I installed "device manager" and took a look into it. Could it be that the "sub-version" Troy James wrote about is from Ricoh Co Ltd.? That is the only non-AMD/ATI-thing I found. But is it related to usb?
Today things got worse: When I started my laptop this morning, both printer and hdd-external drive crashed right away before even using them. At the same time it is extremely slow, as if low on memory. Could there be a connection? Well, maybe not.
So, I am attaching the lspci and lspci -vv and lspci -vvn outputs. And the dmesg-output. In the latter are error messages like "no agp bridge found", "aperture beyond 4GB", "ata1: softreset failed (device not ready)", "ata1: failed due to HW bug, retry pmp=0", some errors with ricoh-mmc, and then of course the "usb 6-1: device descriptor read/64, error -110", "usb 6-1: device not accepting address 2, error -110" and the I/O-errors. Of course, there might be no connection between the different errors.
I hope someone understands what this all means and can help...
Thanks a lot!

[zasq (zasq)]

Another possible source of the error might be that ohci (usb 1 support) is loaded before ehci (usb 2.0 support):
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/296710
In my dmesg log at least the ohci comes before ehci...

[zasq (zasq)]

dmesg after printer-crash (file to be printed had 293 KB). I will try to contact Dell and see what they now about known hardware problems with the chipset an let you know.

[David Becker (becker-david)]

I seem to have solved (i.e., worked around) my previous issues. Note that the "lost page write" errors I'm getting are likely due to the lvm copyonwrite store I'm using. When the store overflows, all kinds of strange things happen, but this is probably unrelated to the issues going on here. "df" output also doesn't reflect the actual usage of the store, so this error may occur when you're not expecting it, i.e. when you would otherwise think you have enough storage space (when actually you don't by virtue of the copyonwrite store overflowing).

Anyway, I've installed linux to a USB drive without the copyonwrite store and I don't have any more disconnect, lost page write or other instability problems. Note that the USB drive and the computer(s) are the same pieces of hardware that were previously producing the errors. All AMD/ATI hardware.

But, I also connected the same USB drive to a Proliant which has (mostly) intel hardware. Low speed USB is uchi while high speed is ehci based.

Now I also got several errors with the Proliant (ehci) which leads me to believe that the errors could likely have something to do with either hald or dbus communication (deficiencies).

I was preparing another live-cd-on-a-usb-stick. This process involves mounting the usb drive, then mounting additional (tmpfs) filesystems to the usb drive, then prepare the drive (formatting), then populate the drive. The copyonwrite store is also involved at this stage.

Now during the preparation stage, with the USB drive mounted, I decided to abort the process. Here's where the errors started occuring. I hit ctrl-c on the process which is creating the livecd-usb and started receiving disconnect errors. Note that a ctrl-c could be analogous to a USB disconnect, although there's also significant differences (since the signals originate from different sources). I manually unmounted the filesystems involved in the preparation process. One would expect that I would then be able to (physically) remove the drive, reinsert the drive and then start the process over, but that wasn't the case. When I reinserted the drive, I couldn't access the drive anymore. No real errors messages, it seems as if the port was unavailable. I did what I normally never have to do (with this machine), I rebooted.

After reboot, I couldn't use that port anymore. I kept getting disconnect errors. Things were going from bad to worse and I rebooted the machine again. I then tried the same process on the front-side ports (was using a port on the back previously). I had no problem performing aforementioned process to completion on the front side port.

I now have this funny feeling that something is going wrong with the mount-state of the filesystems involved. This really reminds me of removing a floppy drive on Sun workstations without having invoked the "eject" command (which unmounts the floppy prior to physically ejecting the floppy disk).

It would seem that "disconnects" are quite normal on a USB bus. It does however get very tricky with the dependencies once a disconnect occurs (is it intermittent or permanent?). This likely differs between devices type (printer daemon and filesystem may respond diffe...

[Forest Bond (forest-bond)]

David,

I can't determine from your rather lengthy comment what makes you think that hal is related to the bug. Care to explain?

Thanks,
Forest

[David Becker (becker-david)]

Sorry for the length ;)

From Wikipedia: "On Linux systems the kernel calls out to udev which in turn provides notifications to HAL through a standard Unix domain socket whenever a device plugs in."

So there's communication triggered by the device connecting, which is relayed through udev on to hald. The Wikipedia page doesn't mention this, but I'm also assuming communication when the device is unplugged.

Let's say a device plugs in. The kernel notices this, triggers something in udev which is relayed to hald which looks up the device and mounts it.

Let's say a (previously connected) device unplugs. What would happen if the (unplug) message doesn't arrive at hald?

Let's say a device plugs in, and then very quickly unplugs and repeats this over and over.

It's possible that hald at one point thinks the device is plugged in (thus available) while it's not or vice versa.

A (plug/unplug) message may get lost. If hald (or udev or even the kernel) doesn't do blocking (of pending signals) correctly or is ignoring when it should be blocking, then a message may get lost.

A lost message would quickly result in a mismatch between the actual device state and what hald (or udev or the kernel) considers to be the (actual) state.

- Disconnects are normal events on a USB bus.
- Windows (tends to) behave differently when filesystems are suddenly disconnected.
- These errors occur on various distro's
- Issue seems to have started from 2.6.21 (or .23)
- Kernel developers apparently don't believe it has anything to do with the kernel
- Issue doesn't (seem to) occur with ohci, thus the source is possibly a race-condition.
- Previous reports on similar issues would be somewhat resolved by introducing a usleep call in the kernel (which probably just delays the occurance of the race condition).
- Lowering of potential throughput (decreasing max_sectors) seems to improve the situation, but really doesn't solve it (= postponement of race-condition).

What is thus involved with mounting? kernel, udev, hald and possibly dbus.

Just a hunch.

David

[Forest Bond (forest-bond)]

Hi David,

If the device is rapidly connecting and disconnecting in a way that isn't contained by the USB subsystem, isn't that going to cause problems for the block device driver and, consequently, the filesystem driver? If you have problems in kernel space, who cares if hal is confused? Aren't things going to head south anyway?

Anyway, I've seen this issue many times running in nothing more than an initramfs environment, without hal.

I don't believe it's accurate to say that "Kernel developers apparently don't believe it has anything to do with the kernel". The kernel bug report that is linked to appears like it may have actually been caused by defective hardware in that particular case. We're probably not seeing a good response from kernel developers because we are trying to piggy-back real bugs on top of a report caused by a hardware defect. We're just not communicating with kernel developers well.

Regards,
Forest

[David Becker (becker-david)]

The kernel probably does it right (one space). But the kernel has to communicate with udev which communicates with hal (transmission across several spaces).

device_connect . udev_called . hald_reads_connect_from_socket . hald_mounts_device ...

What if the device disconnects between hald receiving the connect message and mounting the filesystem? Or, what if the device is mounted, then disconnects and data is written to the device before hald receives the disconnect message?

But, if you see this without hal, then my argument does become very weak.

It's just that everytime I ran into "lost page write" or "buffer i/o errors" it apparently had something to do with a mismatch between what was perceived to be mounted and what was actually (not) mounted or vice versa.

David

[Daniel T Chen (crimsun)]

For those of you with USB 2.0 controllers still experiencing this bug, try building ehci_hcd into your initramfs, i.e., echo ehci_hcd|sudo tee -a /etc/initramfs-tools/modules && sudo update-initramfs -u .

(To note, for 9.04, the usb controller drivers may be built with =Y instead of =M, which works around an embarrassingly high number of symptoms.)

[Forest Bond (forest-bond)]

Hi Daniel,

On Sun, Dec 21, 2008 at 11:15:40PM -0000, Daniel T Chen wrote:
> For those of you with USB 2.0 controllers still experiencing this bug,
> try building ehci_hcd into your initramfs, i.e., echo ehci_hcd|sudo tee
> -a /etc/initramfs-tools/modules && sudo update-initramfs -u .
>
> (To note, for 9.04, the usb controller drivers may be built with =Y
> instead of =M, which works around an embarrassingly high number of
> symptoms.)

It sounds like this defect is understood. Can you provide a link to some kind
of reading material characterizing the bug? I've been seeing this on a lot of
hardware for quite a while, and I'd really like to understand it myself.

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[Thomas Holzeisen (info-holzeisen)]

> For those of you with USB 2.0 controllers still experiencing this bug,
> try building ehci_hcd into your initramfs, i.e., echo ehci_hcd|sudo tee
> -a /etc/initramfs-tools/modules && sudo update-initramfs -u .

This does not change anything for me, I am still getting "disconnects" just they moved from dmesg to syslog. I am using Ubuntu 8.04 AMD64 on a ASUS M3A78 Board (AMD 770 Chipset). Unloading ehci_hcd still keeps the only workaround to me.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[David Morgado (dcrmorgado)]

Hi, since kernel 2.6.27-11.22 that everything is working OK for me, so this problem is fixed. Again, for me anyway.

Just to refresh what I said before I have a SB700 based laptop so this latest kernel has apparently fixed this, and there are a few interesting bits in the change log:

USB: fix SB700 usb subsystem hang bug
USB: fix SB600 usb subsystem hang bug

and a few uvcvideo patches to (webcam)

I think I saw something similar for nvidia or intel stuff, cann't remember...
If some of this patches where to be back ported to hardy would be nice.

Thanks and good luck everyone.

[Troy R. (dsm-iv-tr)]

As of the latest in intrepid-proposed, I get this in dmesg, and USB 2.0 support is working again!

[ 14.483131] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
[ 14.485309] ehci_hcd 0000:00:13.5: applying AMD SB600/SB700 USB freeze workaround

So if you guys want an easy fix, try adding -proposed to your apt sources, pinning it as lower priority, and then installing:

linux-image-2.6.27-11-generic
linux-headers-2.6.27-11-generic
linux-headers-2.6.27-11
linux-restricted-modules-2.6.27-11-generic

Good luck.

[Leann Ogasawara (leannogasawara)]

Hi Everyone,

The kernel in intrepid-proposed sounds promising. For anyone else interested in testing and giving their feedback, refer to https://wiki.ubuntu.com/Testing/EnableProposed .

Additionally, I haven't seen any specific comments that this exists in Jaunty, so I'm marking that task as Incomplete for now.

[Peter Hoeg (peterhoeg)]

Turns out the Intrepid standard kernel gives me the disconnects on my main desktop too, although they don't make the machine lose connectivity to the USB drives - things just work slowly for a brief moment and then everything stabilises again. This machine has an nVidia MCP73 chipset.

The max_sectors fix seem however to do the trick, so here is a udev rule that will make udev set the correct max_sectors on all USB drives automatically and while YMMV it does in fact work for me.

It seems like the safe thing is to default max_sectors to 128 instead of 240 as it works with more chipsets and doesn't require kernel workarounds.

Anyway, drop the following into /etc/udev/rules.d/81-usb_max_sectors.rules and make sure that the SUBSYSTEM line is in fact on one line and not broken into two.

# Set max_sectors to 128 for USB HDDs as the default 240 causes problems
#
SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd*", RUN+="/bin/sh -c 'echo 128 > /sys/block/%k/device/max_sectors'"

I need this machine for work purposes so am a little hesitant to try out the jaunty kernel especially since the workaround works and the workaround can be implemented by policy as opposed to waiting for kernel support.

[Peter Hoeg (peterhoeg)]

Great. Turns out I was a little too hasty. While the udev rule does make the resets happen significantly less frequently, they are still happening. Damn.

In the process of downloading the jaunty kernel and will report back when installed. It does however take forever here in China. The internet connection here might be restricted, slow and unreliable, but at least it's expensive....

[Peter Hoeg (peterhoeg)]

Bad news people.

The linux-image-2.6.27-11-generic packages from -proposed do not fix it for me - with max_sectors set to 128, it doesn't happen as frequently as with max_sectors = 240, but there is no difference between kernels -11 and -9 for me.

Bear in mind, that my chipset is nVidia MCP73 and thus not covered by the AMD SB600/700 workaround (I'm assuming).

I was getting the error about ohci loading first, so I forced ehci_hcd to load first by editing /etc/initramfs-tools/modules, but it still doesn't fix it.

So to sum it up, using the -11 kernel from proposed, max_sectors = 128 and ehci_hcd loading before ohci_hcd and this is what I get:

peter@dolores:~$ dmesg | grep reset
[ 10.052941] usb 1-6.1: reset low speed USB device using ehci_hcd and address 9
[ 937.341197] usb 1-6.2: reset high speed USB device using ehci_hcd and address 10
[ 2341.333491] usb 1-6.2: reset high speed USB device using ehci_hcd and address 10
[ 2957.343520] usb 1-6.2: reset high speed USB device using ehci_hcd and address 10

Any others hints as to what to try out?

[John P. Richardson (paul-reverendlinux)]

More petrol for the fire...

Test Device: Smartparts PXE7 7" LCD digital picture frame
Test System 1: MSI Wind netbook running Xubuntu 8.10 kernel 2.6.27-9-generic
Test System 2: Homebrew kit running Ubuntu 8.10 kernel 2.6.27-11-generic on MSI MS-7253 mainboard.

When I plug the picture frame into the MSI Wind, it works brilliantly.

When I plug the picture frame into the Homebrew system, I get the same problems as everyone else. See the attached excerpt from dmesg.

Reducing the max sectors to 128 or 64 has no effect. Only solution is to sudo modprobe -r ehci_hcd each time I want to access the device.

[igor.lopez (igor.lopez-linux-kernel-bugs)]

I have created a (maybe) similar bug in: http://bugzilla.kernel.org/show_bug.cgi?id=12347
but in my case it is only affecting 64bit kernels with the same symptom,
ehci_hcd does not work and the kernel reverts to using ohci_hcd instead.

[John P. Richardson (paul-reverendlinux)]

And for what it's worth, the Smartparts USB picture frame in my last entry above works fine on the following system:
System: IBM Thinkpad A31 model 2652-XXJ
Kernel: 2.6.24-22-generic
Distro: Xubuntu 8.04 with all updates

[Stefano_PG (slot)]

Not only alcor chipset, even my nforce2 has this problem

[Stefano_PG (slot)]

Here's my log:

chipset Nforce2; USB drive Packard Bell and Trust Bluetooth dongle affected, both wired to USB 2.0 ports.

[Stefano_PG (slot)]

I also tried kernel 2.6.27.11 but it doesn't work neither.
This bug will be 2 years old soon, "Happy birthday!" :-) Are other distros affected by this?

[Jari Laamanen (yartsa)]

Well, debian stable (4.0) with kernel 2.6.26-1-686 has this issue, if you want to count it as an other distro. But 2.6.26 is from testing and with 2.6.22 from stable (or 2.6.17), if I remember correctly, usb worked. I don't use that machine regularly, only noticed that this issue emerged along with the new kernel.

[Stefano_PG (slot)]

With this kernel I have no issues: 2.6.27-7-generic

Maybe other owners of an A7N8* Motherboard should try this. The issue is only with the 2.6.27-9 and the 2.6.27-11.

[cnj5 (ubuntu-bugs-cjlj)]

Tested on two computers & different usb hardware & hd's.

An 8.04LTS install developed this problem. I tried a 8.1 Live CD with 2.6.27-7-generic which worked as expected.

The fresh install of 8.1 worked until updated less than an hour later after installing all the latest updates (inc 2.6.27-9-generic), booting from previous kernel -7 from grub does not fix the problem (same in 8.04LTS) uname reports kernel -7 & rebuilding initrd is -9 not -7?

setting max_sectors seems to make a difference.

sudo modprobe -r ehci_hcd / blacklist doesn't seem to do much on 8.1, as It still seems to be using it:
usb 4-2: new full speed USB device using uhci_hcd and address 4

HD log while copying large files 10GB + backups: time it takes goes from minutes to days,,,, copying freezes before usb reset

usb 5-8: reset high speed USB device using ehci_hcd and address 7
sd 9:0:0:0: [sdf] Sense Key : No Sense [current]
sd 9:0:0:0: [sdf] Add. Sense: No additional sense information
usb 5-8: reset high speed USB device using ehci_hcd and address 7
sd 9:0:0:0: [sdf] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
__ratelimit: 1451 callbacks suppressed
lost page write due to I/O error on sdf1
JBD: Detected IO errors while flushing file data on sdf1

Probably related: USB dvd writer is recognised sometimes and appears to work occasionally goes really slow. or just produces reset error with increasing address number. sorry haven't got round to test, as I am more interested in getting a reliable working usb hd backup.

[Javier (javiervalencia80)]

Hi all, I'm using ubuntu hardy 8.04

uname: Linux esparta 2.6.24-23-generic #1 SMP Thu Nov 27 18:13:46 UTC 2008 x86_64 GNU/Linux

and my usb card reader is not working anymore.
It works if I plug my camera directly but not with the card reader.

Those are the errors on dmesg:

[41596.027957] usb 2-5: reset high speed USB device using ehci_hcd and address 9
[41606.258445] usb 2-5: reset high speed USB device using ehci_hcd and address 9
[41622.481034] usb 2-5: reset high speed USB device using ehci_hcd and address 9
[41622.729888] usb 2-5: reset high speed USB device using ehci_hcd and address 9
[41632.960177] usb 2-5: reset high speed USB device using ehci_hcd and address 9
[41633.094245] sd 15:0:0:0: Device offlined - not ready after error recovery
[41633.045716] sd 15:0:0:0: rejecting I/O to offline device
[41633.045727] sd 15:0:0:0: rejecting I/O to offline device
[41633.045731] sd 15:0:0:0: rejecting I/O to offline device
[41633.045735] sd 15:0:0:0: [sdb] READ CAPACITY failed
[41633.045736] sd 15:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[41633.045740] sd 15:0:0:0: [sdb] Sense not available.
[41633.045744] sd 15:0:0:0: rejecting I/O to offline device
[41633.045747] sd 15:0:0:0: [sdb] Write Protect is off
[41633.045749] sd 15:0:0:0: [sdb] Mode Sense: 00 00 00 00
[41633.045751] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[41633.045814] sd 15:0:0:0: [sdb] Attached SCSI removable disk

I hope it helps :)

[Stefano_PG (slot)]

Try reinstalling the 2.6.27-7, I removed it after the update to -9 and now it works like before.

[Stefano_PG (slot)]

Ok, it's not a complete solution. USB drives usually work (I transferred 4 GB in my device without failures), but it casually resets even without pending operations.
A very little step forward with 2.6.27-7-generic kernel.

[cnj5 (ubuntu-bugs-cjlj)]

Additional: I spent a few days of copying a selection of files to various usb ide/sata interfaces.

Both the controllers are ide with a ide > sata adapter attached, That are the ones producing the the log entries and problems for me. The usbhd cases are from different companies one unbranded the other is branded safecom model# su2sj-35caf 2006 they both report themselves (via lsusb) as:

Device 018: ID 067b:2507 Prolific Technology, Inc. PL2507 Hi-speed USB to IDE bridge controller

They did not produce any errors or seem to have any problems until recently when a tgz backup file failed copying to one of the devices.

After loads of testing the PL2507 can copy some files with out a problem and others just produce an occasional random reset (sometimes without one) with no apparent affect. They seem to work best using the 8.1 live cd but the problems still occur, not enough to always be noticeable. After install and update to latest kernel -9 in 8.1 it seems to get much worse.

I have tried both small & large files, it is normally the larger files that have more of a problem. 50mb+.

I found one large 12gb sony dv camera avi file that errors every single time, at different positions what ever kernel version 7.1, 8.04LTS and 8.1 when copying to both of the PL2507 devices. The AVI file copies normally on other controllers with the same HD

The file attached contains the pl2507 chip markings, lsusb - v and log entries when copying a file to drive.

[Hated On Mostly (mostly-hated-on)]

Ubuntu Kernel Team needs to be notified and subscribed to this bug.

This bug is also related to this bug:

https://bugs.launchpad.net/ubuntu/+bug/177235

An older kernel that works perfectly is

2.6.24-19 which is the default install kernel for Ubuntu v8.04.1. Once you update the kernel you get USB 1.0 speeds and transfer problems.

Also see this post for other evidence:

http://ubuntuforums.org/showpost.php?p=6560662&postcount=59
http://ubuntuforums.org/showpost.php?p=6543011&postcount=56
http://ubuntuforums.org/showpost.php?p=6560824&postcount=60
http://ubuntuforums.org/showthread.php?t=793688

This bug can be found on multiple distributions. The problem is with the kernel.

[Hated On Mostly (mostly-hated-on)]

The problem still occurs with latest kernel version 2.6.28

--------------------------------------------

Ubuntu Kernel Team needs to be notified and subscribed to this bug.

This bug is also related to this bug:

https://bugs.launchpad.net/ubuntu/+bug/177235

An older kernel that works perfectly is

2.6.24-19 which is the default install kernel for Ubuntu v8.04.1. Once you update the kernel you get USB 1.0 speeds and transfer problems.

Also see this post for other evidence:

http://ubuntuforums.org/showpost.php?p=6560662&postcount=59
http://ubuntuforums.org/showpost.php?p=6543011&postcount=56
http://ubuntuforums.org/showpost.php?p=6560824&postcount=60
http://ubuntuforums.org/showthread.php?t=793688

This bug can be found on multiple distributions. The problem is with the kernel.

[Stefano_PG (slot)]

So, Hated On Mostly, with the patch you posted on ubuntuforums we can have USB 2.0 transferts in flash drives, but the CD drive start working even if you don't use it?

[Martin Lubich (mlubich)]

>An older kernel that works perfectly is
>2.6.24-19 which is the default install kernel for Ubuntu v8.04.1. Once you update the kernel you get >USB 1.0 speeds and transfer problems.

Quite frankly, in this generality thats not true. It may be true for you in your current specific environment, but not for a lot of others.

As the true nature of the bug ( or multiple bugs ) is not really understood, allthough it most probably lies within the kernel, any 'workarounds' thus far provided (mine no exception) is wild guessing at best.

This bug needs attention fro the kernel developers and tackled in an organized way. Here the ubuntu developers could aid in providing the necessary evidence,data and feedback to get this issue resolved.

So far any bugs reported to the kernel developers give the picture of single unrelated occurances the the developers , as there is no organized report there, pointing at the dimension of the problem.

I for my part have resigned and remain very pessimistic that this gets resolved any time soon. For my part I have found a workaround for my environment (put in an additional USB controller card), but as already mentioned thats not a solution. Changing the environment will most probably break the workaround as well.

[Bill Smith (bsmith1051)]

Another affected system:
- Ubuntu 8.10 with current patches
- ATI "740G" motherboard (SB700 chipset, I've attached my lspci printout)

Disabling 'ehci' seems to workaround the problem, and it also seems to work properly using the Ubuntu 8.04.1 LiveCD, at least for a quick test.

[Tommy Vestermark (tov)]

I can confirm that the bug is still present in Intrepid with kernel 2.6.27-9-generic on my AMD 780G board with an SB700 southbridge (A Gigabyte GA-MA78GM-S2H)... but...

After upgrading to kernel 2.6.27-11-generic from Intreprid Proposed it seems to have solved the problem. Refer to Leann Ogasawaras message from 2008-12-24 and the two previous messages for further info. Now I can finally put my old AT backup keyboard in the attic again :-)

[Hated On Mostly (mostly-hated-on)]

>So, Hated On Mostly, with the patch you posted on ubuntuforums we can have USB 2.0 transferts in flash drives, but >the CD drive start working even if you don't use it?

The patch works for me, but not as good as a live CD Ubuntu v8.04.1. It will pause sometimes during a transfer, but usually the speed recovers and finishes the transfer. The patch just disables sync mode for USB devices. Definitely not a perfect fix, but it might get you by. I am going to use the patch long enough to backup my data and redo my system. Unreliable USB transfers is unacceptable so I can't run my system in this state and the patch is not a good fix for a production system.

The problem with the solution I posted is that it was designed to solve the problem for opensuse versions 9.3-10.0 and thus is several years old. Yes this bug is several years old and across multiple distributions (I have seen this problem mentioned for Debian, Mandriva, Fedora, Suse/Opensuse and a few others I forget) if you check out some of those links from the ubuntuforums. I think the oldest complaint I saw about slow/buggy usb transfers is from 2002!

There was another usb bug/ehci bug on here that showed a whole bunch of problems with each tiny change in the 2.6.24-x series and then the Ubuntu Kernel Team regressed the changes which broke everything for 2.6.24-19 which is the kernel in the default install of 8.04.1.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/212660
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/212660/comments/19

It's crazy that USB can be so broken between the smallest updates and it goes completely unacknowledge by so many developers across distributions, but that is where we are right now.

My next step is to install 8.04.1, lock the kernel, update it to intrepid via alternate CD and see what happens. If it breaks then I have to switch to BSD or Mac OSX depending on whether or not I can get whole disk encryption setup properly with BSD.

[Hated On Mostly (mostly-hated-on)]

Testing a possible temporary solution. Try it if you are brave, although no problems experienced for me.

Try replacing the file "ehci_hcd.ko" which is located in

/lib/modules/<kernel version number>-generic/kernel/drivers/usb/host

With the same file from a kernel version that USB transfers work just fine for you.

For example, I replaced my file on the current system with the "ehci_hcd.ko" file from the live CD of Ubuntu v8.04.1, which I found in the following location:

/lib/modules/2.6.24-19-generic/kernel/drivers/usb/host

I am in the middle of preliminary testing, but so far it seems to have fixed the problem for me using kernel 2.6.27-10. It seems to be giving me the same performance I get from the live CD in which transfers work just fine. Will report back later, hopefully someone else with this problem will try it out and let us know his/her experience.

[archdrone (archdrone)]

With 2.6.28 series kernel I found "Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after" in output of `dmesg` so I rmmoded all *_hcd modules and modprobed them in correct order. So far the problem seems to be gone (testing 2 days). Can anyone confirm?

[Stefano_PG (slot)]

I spent all the day testing kernels from 2.6.27-7 to 2.6.27-11 .

Conclusions:

- Kernel 2.6.27-7 works only if you never upgrade and if there aren't any other kernel installed,
- Other kernels ant the "not fresh" -7 can operate for some time, but usually after 1-2 successful transfers of files the ehci-hcd module stop working at all for that kernel.

@archdrone

Do you have to rmmoded every boot?

[Ka-Hing Cheung (kahing)]

> I can confirm that the bug is still present in Intrepid with kernel 2.6.27-9-generic on my AMD 780G board with an SB700
> southbridge (A Gigabyte GA-MA78GM-S2H)... but...
> After upgrading to kernel 2.6.27-11-generic from Intreprid Proposed it seems to have solved the problem. Refer to
> Leann Ogasawaras message from 2008-12-24 and the two previous messages for further info. Now I can finally put
> my old AT backup keyboard in the attic again :-)

I have a 780G based board as well but it's from ECS, 2.6.27-11-generic from -proposed didn't fix it, neither did lowering max_sector, or a combination of the two. Unloading ehci did workaround it though, but higher transfer speed would be ideal.

[Bill Smith (bsmith1051)]

ok, so I take back what I'd posted previously about 8.04.1 LiveCD working properly -- it doesn't.

instead, the Ubuntu 9.04 Alpha-3 LiveCD works perfectly! At least for my SB700 chipset it seems like it'll be fixed on this next release.

[Stefano_PG (slot)]

I read about "... stable USB drivers..." from the 2.6.28 changelog. Maybe it's the end for this bug? I would like testing the 2.6.28 but I'm not confident with kernel settings.

[Denilson Sá (denilsonsa)]

On Tue, 20 Jan 2009 06:35:16 -0200, Stefano_PG <email address hidden> wrote:

> I read about "... stable USB drivers..." from the 2.6.28 changelog.
> Maybe it's the end for this bug? I would like testing the 2.6.28 but I'm
> not confident with kernel settings.

I read that at ubuntugeek, but couldn't found anything related to such
"stable usb drivers" in kernel changelog. At least not anything relevant
to this bug.

--
Denilson Figueiredo de Sá
Vialink / Dream Solutions
Rio de Janeiro - Brasil

[Stefano_PG (slot)]

In facts this kernel works as bad as the others. It complete transfers about one or two times, than starts hanging and reseting the USB driver. I tried the one from Jaunty repos, 2.6.28.4

The only secure and stable solution is to rmmod every boot ehci-hcd.

[Hated On Mostly (mostly-hated-on)]

After a lot of testing it appears that only the original release kernels work well for me.

8.04 (2.6.24-16), 8.04.1 (2.6.24-19), 8.10 (2.6.27-7) USB transfers go smoothly as long as I don't update the kernel. Every single kernel update messes up USB transfers for me. I have tried all of the Intrepid proposed and Jaunty kernel updates and none of them worked well for me including the new 2.6.28.x series.

In order to lock down the kernel so you don't see updates in the update manager, make sure you lock the versions of everything in synaptic including for versions you don't have installed for the following items.

linux-generic
linux-headers
linux-image
linux-restricted-modules

Once I locked all of these down (both installed and uninstalled), I was able to do updates without seeing any updates for the kernel.

[Peter Hoeg (peterhoeg)]

Am taking the liberty of changing the status for intrepid as a fix has most certainly not been committed and I want to make sure this bug doesn't fall off the radar.

[Stefano_PG (slot)]

Look here: http://bugzilla.kernel.org/show_bug.cgi?id=11030

They say:

status:rejected
resolution:invalid

[cnj5 (ubuntu-bugs-cjlj)]

I also have another device with the same problems usb -> ide / sata drive.

Bus 005 Device 056: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

motherboard usb:
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)

currently working usb-->sata devices

maxtor one touch:
Bus 005 Device 057: ID 0d49:7200 Maxtor

Bus 005 Device 058: ID 0d49:3210 Maxtor
Bus 005 Device 059: ID 152d:2336 JMicron Technology Corp. / JMicron USA Technology Corp.

If there is a kernel developer willing to pay the postage, I am willing to donate my sata drive case (PL2507) mentioned above to help get this problem sorted out.

[Hated On Mostly (mostly-hated-on)]

archdrone or Stefano_PG

Could either of you make a script or post detailed instructions on your workaround?

Thanks

-------
>With 2.6.28 series kernel I found "Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after" in >output of `dmesg` so I rmmoded all *_hcd modules and modprobed them in correct order. So far the problem seems to >be gone (testing 2 days). Can anyone confirm?
------
>The only secure and stable solution is to rmmod every boot ehci-hcd.
-------

[Stefano_PG (slot)]

My workaround has really simple: just put in /etc/rc.local, just above "exit 0", this line:

/sbin/modprobe -r ehci-hcd

To remove USB 2.0 and force your devices in a USB 1.1 "compatibility mode". It is a very stable solution, but the transfer rate is lower (1, 1,5 MB/s).

I'm trying archdrone's solution on my 2.6.27-9 kernel instead. This is what you should do to replicate it:

1) Create a file:

sudo gedit /usr/local/bin/modprobe-usb

2) Copy this in the file:

#!/bin/bash
/sbin/modprobe -r ehci-hcd
/sbin/modprobe -r uhci-hcd
/sbin/modprobe -r ohci-hcd
/sbin/modprobe ehci-hcd
/sbin/modprobe ohci-hcd
/sbin/modprobe uhci-hcd

3) save and close

4) give execution right to the file:

sudo chmod a+x /usr/local/bin/modprobe-usb

5) write in /etc/rc.local, just above "exit 0"

/usr/local/bin/modprobe-usb

6) save, close and reboot. You are now ready to test.

If something goes wrong reboot in recovery mode, select the root shell and execute this command:

rm /usr/local/bin/modprobe-usb

You should be able to boot up again and remove the line added in /etc/rc.local

------------

I moved this way 4,5 GB, 7 files. Then I rebooted, I removed those files and I moved the same files again.
No USB resets, transfer rates of about 6 MB/s

I'm still testing.

[Stefano_PG (slot)]

DON'T DO THAT!!!!

by rmmodding those modules you will brake several other and your system may not work. Fortunately you can remove the file as in 7) and than remove the line in rc.local, so all should be the same again.

I have tested another way to modprobe the modules in the right order. Simply open rc.local:

sudo gedit /etc/rc.local

and add these lines:

/sbin/modprobe -f ehci-hcd
/sbin/modprobe -f uhci-hcd
/sbin/modprobe -f ohci-hcd

I moved 7,5GB from pata to usb, than from usb to pata; then I reboot, and I moved the same files again from pata to usb and to usb from pata. In the meantime I was using some files in the USB drive to stress it more.

Again, as above, no usb reset at all and a great improve in speed: from 6MB/s to 22MB/s. I don't know why, but I'll continue the tests.

[Stefano_PG (slot)]

Sorry, it resets.

This workaround does not work, the only thing to do is to rmmod ehci-hcd.

[ezoltan (enzoltan)]

Hi everybody,

I have removed ehci-hcd and disabled USB 2.0 in the BIOS. So I get the next message in the syslog:

"Jan 26 07:55:08 localhost kernel: usb 1-10: new full speed USB device using ohci_hcd and address 2
Jan 26 07:55:09 localhost kernel: usb 1-10: device descriptor read/64, error -62
Jan 26 07:55:09 localhost kernel: usb 1-10: device descriptor read/64, error -62
Jan 26 07:55:09 localhost kernel: usb 1-10: new full speed USB device using ohci_hcd and address 3
Jan 26 07:55:09 localhost kernel: usb 1-10: device descriptor read/64, error -62
Jan 26 07:55:09 localhost kernel: usb 1-10: device descriptor read/64, error -62
Jan 26 07:55:10 localhost kernel: usb 1-10: new full speed USB device using ohci_hcd and address 4
Jan 26 07:55:10 localhost kernel: usb 1-10: device not accepting address 4, error -62
Jan 26 07:55:10 localhost kernel: usb 1-10: new full speed USB device using ohci_hcd and address 5
Jan 26 07:55:11 localhost kernel: usb 1-10: device not accepting address 5, error -62 "

As I see it, I can't use ohci_hcd module too. So I can' t use my pendrive and outside winchester.
I tryed load usb-stotage modul, but it does not work too.

At least I would like use my pendrive slow.

[simon (simon-segfault-info)]

Hello,

i am also affected by this bug...

my mainboard is an asus m3a78-t: amd 790gx chipset, amd sb750 southbridge.

i don't know if it may help anyone, but atleast for me, i can reproduce the usb "reset"
bug very easily with running an md5sum against my usb2.0 storage devices...
(sudo md5sum /dev/sdX)

wich, in my case, will trigger usb resets quite fast.

i can reproduce this behavior with two of my usb 2.0 hdds, one western digital mybook
(2.5" 250gb) and one seagate freeagent (3.5" 500gb).

fyi, i tried the following "fixes", but usb2.0 is still exhibiting the "reset" bug:
- kernel 2.6.27-11 from intrepid-proposed
- ensuring that ehci_hcd is loaded before ohci_hcd/uhci_hdc
- disabling usb autosuspend as recommended in comment #209

so when i run md5sum against my wd mybook or seagate freeagent, it's at some point
starting to reset:
[ 3373.785540] usb 3-5: reset high speed USB device using ehci_hcd and address 4
[ 3388.896040] usb 3-5: device descriptor read/64, error -110
[ 3404.112046] usb 3-5: device descriptor read/64, error -110
[ 3404.328024] usb 3-5: reset high speed USB device using ehci_hcd and address 4
[ 3419.440041] usb 3-5: device descriptor read/64, error -110
[ 3434.656037] usb 3-5: device descriptor read/64, error -110
[ 3434.873731] usb 3-5: reset high speed USB device using ehci_hcd and address 4
[ 3445.280030] usb 3-5: device not accepting address 4, error -110
[ 3445.392051] usb 3-5: reset high speed USB device using ehci_hcd and address 4
[ 3455.801525] usb 3-5: device not accepting address 4, error -110
...

[davotibarna (davotibarna)]

Hi guys,

I run an up-to-date Ubuntu 8.10. I'm having trouble with an external USB DVD burner. It used to work just fine before with Sabayon and WinXP.

Now with the latest Ubuntu it's very hectic. Sometimes it burns the disk correctly, but mostly the process stops after a few MB is burnt and it hangs - whatever software I use.

I get this in /var/log/messages:
Jan 28 23:37:06 oslo kernel: [258468.744247] usb 7-1.6: reset high speed USB device using ehci_hcd and address 12

Reading this log "Hated On Mostly" suggests to roll back to the original kernel, that should work fine.
I did, but unfortunately it did not solve the problem. I still get this USB reset error.

Checked the kernel version, just to be sure:
uname -r
2.6.27-7-generic

[Hated On Mostly (mostly-hated-on)]

>
>Reading this log "Hated On Mostly" suggests to roll back to the original kernel, that should work fine.
>I did, but unfortunately it did not solve the problem. I still get this USB reset error.
>

Rolling back won't work. Once you update the system, you cannot fix it by switching kernels. You have to do a fresh install with the kernel that works.

[Andy Rabagliati (andyr)]

davotibarna,

Please run the command 'lspci -vvnn > lspci-vvnn.log' and attach the resulting file 'lspci-vvnn.log' to this bug report.

Do you have any USB 1.X devices or hubs ? The solution for me (documented above) was to unplug the USB multi-card reader thing from my computer. I did not have to remove the ehci module.

[davotibarna (davotibarna)]

Andy Rabagliati wrote:
> davotibarna,
> Please run the command 'lspci -vvnn > lspci-vvnn.log' and attach the
> resulting file 'lspci-vvnn.log' to this bug report.

Attached.

> Do you have any USB 1.X devices or hubs ? The solution for me
> (documented above) was to unplug the USB multi-card reader thing from my
> computer. I did not have to remove the ehci module.

My box is in the basement while I'm sitting one floor above with a
screen and USB devices (keyboard, mouse, DVD burner, card reader). The
USB cable is 5m long, but I use two powered USB hubs, which used to work
just fine for about 2.5 years. The perfect noiseless computer. :-)

I'm not aware of any USB 1.x device.... or maybe my Palm Tungsten C
cradle is USB 1.0 (about 5 years old)?

The new kernel just came out yesterday (2.6.27.11). Should I upgrade?
Nothing to loose I guess...

[Stefano_PG (slot)]

You shouldn't expect improvements: this kernel runs exactly as the others do. I read that now the kernel "shows a warning when the USB modules are not loaded in the right order" (or something similar to the 2.6.28-4 warning), but 5 minutes ago it resets and I have not seen nothing different in my dmesg.

[davotibarna (davotibarna)]

Just completing my story. Tested the new ubuntu kernel, no change...
so I gave up playing with the usb interface and moved the DVDR into
the box connecting with the PATA interface. Surprisingly I got the
same problem with PATA also. At that point I just got the idea it has
to be a hardware issue. This drive is about 4 years old, I used a lot,
no problems before at all.

I bought a new Plextor DVDR drive. Tested with PATA first and so
started to use via USB. ... and it just works fine. I still get the
reset issues in the log, but somehow the software does not seem to be
bothered by that and it just works perfectly. Burnt at least a dozen
DVDs since and haven't faced a single problem.

To be honest I did not expect a hardware issue right now, since I just
bought a new computer. The device used to work fine with the old box
running XP, but never worked with the new one running linux.

[vkweb (vkweb-linux-kernel-bugs)]

Hello.

It seems that I've got same problem in Debian Lenny, kernel 2.6.26-1-686 on Dell Inspiron 1501 (RS480 + SB600 chipset).
I found this problem with external box for HDD with chip ID 04fc:0c15 Sunplus Technology Co., Ltd (LC Power EH-25BSII).
After this log in dmesg (it is there more times):
[ 4479.602066] usb 1-1: reset high speed USB device using ehci_hcd and address 2
[ 4494.714952] usb 1-1: device descriptor read/64, error -110
[ 4509.931822] usb 1-1: device descriptor read/64, error -110

This box completely freezes and I must force plug out this box. After that I must reload ehci_hcd module.
Ohci_hcd and uhci_hcd modules are not loaded in that moment.
After that it works, but it is not good for filesystem and HDD inside because it always hangs while it is reading or writing data.
Connecting additional power supply doesn't help.

With my another USB->SATA converter with JMicron chip (idVendor=152d, idProduct=2338) it doesn't cause this problem.

I hope it could be helpful.

[stern (stern-linux-kernel-bugs)]

Created attachment 20097
Make EHCI retry transaction errors 32 times

For those of you with problems caused by hubs or KVMs, you can try out this patch (which is based on 2.6.28, although it might also work with earlier kernels). I have no idea whether it will fix all of your problems, but there's a good chance it will fix some of them.

[vkweb (vkweb-linux-kernel-bugs)]

I applied your patch on debian lenny kernel 2.6.26-1-686 and I turn on usb debugging and with testing command

for f in `seq 100`; do dd if=/dev/zero of=test bs=64k count=6000; done

it works ok, but if I do

rsync -av --delete --progress /mnt/local_disk/ /mnt/external_disk/

and if I stop this process with Ctrl+Z in gnome-terminal, take it in this state for about 2 minutes and then fg this process external hdd freezes after about 10 seconds and dmesg says:

[ 2320.736733] ehci_hcd 0000:00:13.5: port 1 high speed
[ 2320.736743] ehci_hcd 0000:00:13.5: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
[ 2320.792730] usb 1-1: reset high speed USB device using ehci_hcd and address 2
[ 2325.793089] usb 1-1: usb-storage timed out on ep0in len=0/64
[ 2330.793390] usb 1-1: usb-storage timed out on ep0in len=0/64
[ 2335.793668] usb 1-1: usb-storage timed out on ep0in len=0/64
[ 2335.849613] ehci_hcd 0000:00:13.5: port 1 high speed
[ 2335.849622] ehci_hcd 0000:00:13.5: GetStatus port 1 status 001005 POWER sig=se0 PE CONNECT
[ 2335.905595] usb 1-1: device descriptor read/64, error -110

 while I disconect external HDD. Now I don't need to reload ehci-hcd module, because after reconnecting of HDD it works OK.

[vkweb (vkweb-linux-kernel-bugs)]

(In reply to comment #61)
> I applied your patch on debian lenny kernel 2.6.26-1-686 and I turn on usb
> debugging and with testing command
>
> for f in `seq 100`; do dd if=/dev/zero of=test bs=64k count=6000; done
>
> it works ok, but if I do
>
> rsync -av --delete --progress /mnt/local_disk/ /mnt/external_disk/
>
> and if I stop this process with Ctrl+Z in gnome-terminal, take it in this
> state
> for about 2 minutes and then fg this process external hdd freezes after about
> 10 seconds and dmesg says:
>
> [ 2320.736733] ehci_hcd 0000:00:13.5: port 1 high speed
> [ 2320.736743] ehci_hcd 0000:00:13.5: GetStatus port 1 status 001005 POWER
> sig=se0 PE CONNECT
> [ 2320.792730] usb 1-1: reset high speed USB device using ehci_hcd and
> address
> 2
> [ 2325.793089] usb 1-1: usb-storage timed out on ep0in len=0/64
> [ 2330.793390] usb 1-1: usb-storage timed out on ep0in len=0/64
> [ 2335.793668] usb 1-1: usb-storage timed out on ep0in len=0/64
> [ 2335.849613] ehci_hcd 0000:00:13.5: port 1 high speed
> [ 2335.849622] ehci_hcd 0000:00:13.5: GetStatus port 1 status 001005 POWER
> sig=se0 PE CONNECT
> [ 2335.905595] usb 1-1: device descriptor read/64, error -110
>
> while I disconect external HDD. Now I don't need to reload ehci-hcd module,
> because after reconnecting of HDD it works OK.
>

I also tested this procedure on Debian Lenny with vanilla kernel 2.6.28.3 without any patch and I transfered about 160GB to/from external HDD without any errors (there was no ehci-hcd error like on 2.6.26-1-686 kernel). So it seems to be OK with this the newest kernel version for me.

[Vitaliy Yermistov (vantoo)]

I had the same problem. I searched many forums and bug-reports, tried many advices like this
--------------------------------------------------------------
1. Type the following in a terminal window:
         sudo gedit /etc/modprobe.d/usb-core-options
2. Add the following line to the usb-core-options file:
        options usbcore autosuspend=-1
3. Save your changes, and then type the following in a terminal window:
      sudo update-initramfs -u
4. Shutdown and power on your computer. (Don't use the restart option)
------------------------------------------------------------
and this
------------------------------------------------------------
Drop the following into /etc/udev/rules.d/81-usb_max_sectors.rules and make sure that the SUBSYSTEM line is in fact on one line and not broken into two.

# Set max_sectors to 128 for USB HDDs as the default 240 causes problems
#
SUBSYSTEM=="block", BUS=="usb", KERNEL=="sd*", RUN+="/bin/sh -c 'echo 128 > /sys/block/%k/device/max_sectors'"
-----------------------------------------------------------

But nothing helped me, my external hard drive and mp3-player not worked properly (though flash drives and other USB-devices worked fine).
Few day ago I bought PCI 5-port USB 2.0 Host Controller based on VIA VT6212 (it is only 7-9 euro in Ukraine) and now all my devices work perfectly when I connect its to this controller.

[Stefano_PG (slot)]

I gave up, so I bought one too. In Italy it costs nearly the same, mine is a 4-ports (3 out - 1 in) based on the same chipset.
My first tests report it working with actual Intrepid and Jaunty kernel. I'm not using workaround anymore.

[Hated On Mostly (mostly-hated-on)]

Unfortunately, I am on a laptop. No option of getting another USB controller for me and others.

[Stefano_PG (slot)]

I can finally use my USB drive without worries, but I'm not resigned to see this bug fixed. Keeping this thread active with log and reports is the only thing we can do now, obviously my next laptop will be 100% intel.

[Hated On Mostly (mostly-hated-on)]

Be careful with going all Intel for a laptop as a solution. I am using a Dell which is all Intel as far as USB controller and other parts go and I experience this problem.

[Hated On Mostly (mostly-hated-on)]

There is a guy on the Ubuntu forums who is willing to allow remote access to a fresh install of Ubuntu on his machine if any developers want to analyze a machine with this problem.

http://ubuntuforums.org/showpost.php?p=6740141&postcount=89

[falk (z-launchpad-net-efalk-org)]

One more data point:

Ubuntu 8.04, hardy
kernel: 2.6.24-23-386
Fresh reboot

Endless stream of "kernel: [ 1430.609432] usb 5-6: new high speed USB device using ehci_hcd and address 109" messages.

Epson 2400 scanner does not work.

Messages stop if I "modprobe -r ehci_hcd"

Scanner now works.

[Hated On Mostly (mostly-hated-on)]

Stefano_PG wrote
>Look here: http://bugzilla.kernel.org/show_bug.cgi?id=11030
>
>They say:
>
>status:rejected
>resolution:invalid
>

This bug looks like it might be similar to the closed bug.

Bug 11159

http://bugzilla.kernel.org/show_bug.cgi?id=11159

Hopefully someone is looking into this over at the official kernel.

[ezoltan (enzoltan)]

Hi,

It seems to I solved this problem. I use Debian. Above problem takes for about 1,5 months.
Yesterday, before I changed the kernel. Now, I use 2.6.26-1-amd64 kernel and pendrive works normaly.

[Mike Berkley (mike-berkley)]

Rather than fiddle with rmmod, perhaps loading ehci_hcd in the initrd.img file is the answer. It certainly seems to have resolved my problems, with fully patched Hardy....

1. Add to /etc/initramfs-tools/modules:
    ehci_hcd

2. Reconfigure current kernel:
    dpkg-reconfigure linux-image-2.6.24-23-server

3. Reboot.

dmesg confirms that ehci_hcd is loaded before ohci_hcd, and that my usb_storage device is using ehci_hcd. I'm getting about 27MB/s write, and about 10MB/s read&write onto the disk, without errors.

[TJ (tj)]

Re-assigning to upstream bug "reset high speed USB device using ehci_hcd".

A comment (#55) there from Alan Stern:

"Your conclusions look right. And they would explain the disk problems: Many
EHCI controllers have a bug which causes them to temporarily drop data on one
port when a device on a different port disconnects. I'd say that whatever is
causing the keyboard communications to drop out manages, every so often, to
interfere with the disk traffic.

The computer then tries to reset the disk drive, but many USB drives have a bug
which prevents them from resetting correctly when they're in the middle of an
I/O operation. As a result, the drive becomes unusable and the system puts it
offline.

As for what causes the keyboard problems... I don't know. It could simply be a
cabling issue. For example, I've got a USB-to-PS/2 keyboard+mouse converter.
It doesn't work at all when plugged directly into my computer, but it works
just fine when connected through a USB extension cable. Try and figure that
one out!

You could try using a different keyboard. Maybe it wouldn't get all those
communications dropouts when plugged into the DLink hub or the ATEN switch."

Later Alan provides a patch:

"Make EHCI retry transaction errors 32 times

For those of you with problems caused by hubs or KVMs, you can try out this
patch (which is based on 2.6.28, although it might also work with earlier
kernels). I have no idea whether it will fix all of your problems, but there's
a good chance it will fix some of them."

When I get a chance I'll add the patch to the Jaunty (2.6.28) kernel and provide test kernels.

[Bill Smith (bsmith1051)]

I just tried Mike's suggestion,
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/500
re ' /etc/initramfs-tools/modules' and it seems to have fixed my setup?!
(see my bug for my complete setup and test case, https://bugs.launchpad.net/bugs/313603 )

I did *not* tweak my kernel image, either, so that step seems to have been unnecessary. Is that even possible, though, or is it impossible that editing the 'modules' file alone could change the order in which OHCI and EHCI load?

[TJ (tj)]

When the USB drivers are dynamically loaded modules as they are in Hardy 8.04 and Intrepid 8.10 the load order can be controlled in the initial RAM-disk image (initrd) by listing module names in the required load order in "/etc/initramfs-tools/modules" and then rebuilding the initrd images stored in /boot/ using the command:

sudo update-initramfs -u -k all

[Peter Hoeg (peterhoeg)]

@TJ: as pointed out in an earlier comment - https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/447 - the load order does not fix it for everybody. I'm guessing it's just covering up the error in your case.

[TJ (tj)]

On Thu, 2009-03-26 at 05:15 +0000, Peter Hoeg wrote:
> @TJ: as pointed out in an earlier comment -
> https://bugs.launchpad.net/ubuntu/+source/linux-
> source-2.6.20/+bug/88746/comments/447 - the load order does not fix it
> for everybody. I'm guessing it's just covering up the error in your
> case.
>
I was answering Bill Smith's question there.

The patch I've attached may well address the issue but I've not yet had
chance to build a test kernel for it for users to test.

[chad (chad-jensen-comcast)]

I experienced this bug as well. I tried all the fixes in this thread as well as other sites but nothing worked. Sometimes my usb would die and lose all power and a restart wouldn't even bring back power. I could unplug and replug in my flash drive and it would be assigned a new address or I would have to totally shut down and reboot to reset my usb system. That made me think that the kernel was making my usb system crash at the bios level. I disabled my usb 2.0 in bios and it worked but I had usb 1 transfer speeds. So I disabled bios legacy support and re-enabled bios 2.0 on chip contoller. It again caused my usb to crash on large files and caused a slow down in transfers on small files. I read about plug and play crashing the usb on another thread (http://marc.info/?l=linux-usb-devel&m=106789579416232&w=2) and looked in my plug and play configurations in my bios. There was a option to assign irq to usb that was enabled. I disabled it and now have had no problems with transferring files. I think some people with this problem might be helped by this fix.

I have award bios (not sure the version) and am running ubuntu 8.04.1 fully patched

Chad

[chad (chad-jensen-comcast)]

sorry got the link wrong in the previous post. The correct link is http://search.luky.org/linux-kernel.2003/msg70535.html. It proved to me that the kernel can crash aspects of bios. I have a usb mouse as well but I wouldn't lose that when the usb crashed in bios. Maybe it uses usb 1.1 transfers.

[chad (chad-jensen-comcast)]

I don't know how to edit posts but I just had the flash drive stall on transfer of files to my computer but at least it didn't lose all power like before. Still geting the usb 1-7: device descriptor read/64, error -110.
Chad

[Andy Rabagliati (andyr)]

Mike's solution in
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88746/comments/500

(Change load order in initrd image) did indeed fix it for me. I rebuilt the initrd for my kernel.

Using Intrepid, 2.6.27-9-generic,
ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer

Up until now unplugging the Alcor Flash reader has been necessary to get the machine to operate.

[Andy Rabagliati (andyr)]

Ugh. I spoke too soon. I had ehci blacklisted. In summary, unplugging the Alcor Flash reader allows me to keep ehci, but leaving it in causes "reset high speed USB device" events.

[VSJ (vsj08)]

Hello, I've bought an external hard disk casing, but I can't get it working under Ubuntu intrepid.

kernel version:

Linux stest 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux

output of dmesg after connecting the external hdd to my laptop, a Dell Latitude D820

[ 8259.872079] usb 5-4: new high speed USB device using ehci_hcd and address 15
[ 8265.643188] usb 5-4: configuration #1 chosen from 1 choice
[ 8267.743143] scsi10 : SCSI emulation for USB Mass Storage devices
[ 8267.751026] usb-storage: device found at 15
[ 8267.751034] usb-storage: waiting for device to settle before scanning
[ 8272.748418] usb-storage: device scan complete
[ 8278.360077] usb 5-4: reset high speed USB device using ehci_hcd and address 15
[ 8295.536082] usb 5-4: reset high speed USB device using ehci_hcd and address 15
[ 8318.712064] usb 5-4: reset high speed USB device using ehci_hcd and address 15
[ 8325.895630] usb 5-4: reset high speed USB device using ehci_hcd and address 15
[ 8343.072074] usb 5-4: reset high speed USB device using ehci_hcd and address 15
[ 8350.133150] scsi 10:0:0:0: Device offlined - not ready after error recovery

output of lsusb

Bus 005 Device 015: ID 058f:6390 Alcor Micro Corp. USB 2.0-IDE bridge
Bus 005 Device 013: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth
Bus 005 Device 002: ID 413c:a005 Dell Computer Corp. Internal 2.0 Hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 046a:0023 Cherry GmbH Cymotion Master Linux Keyboard
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 006: ID 046d:c016 Logitech, Inc. M-UV69a/HP M-UV96 Optical Wheel Mouse
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 007: ID 0b97:7762 O2 Micro, Inc. Oz776 SmartCard Reader
Bus 002 Device 006: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

I've also tried connecting it to a new computer with a Gigabyte GA-MA78GM-S2H mainboard.
--> doesn't work
And also with another computer, with a nForce based chipset, it doesn't work.
USB 1.1 mode works "fine" ( harddrive gets mounted, but is unusable slow)

[andrej (andrej-linux-kernel-bugs)]

I can see a similar problem with a Samsung DVD writer. There are many resets and inexplicable I/O errors in the logs. Re-connecting the drive does not help. Tested with *two* Samsung SE-S224Q drives, so drive malfunction is unlikely, and with two computers, a server and a laptop. The frequency of errors was approximately the same in all cases.

Some more facts:

DVD+RW with UDF:
    * Usually mounts and unmounts cleanly with no error messages.
    * Device resets always appear in bursts of about ten.
    * Writing a large amount of data often leads to media damage.

DVD-RAM with Reiser4:
    * Numerous (> 30) resets occur when the FS is mounted.
    * Unmounts are usually quick and clean.
    * I/O errors are reported approximately once per 10 resets.
    * Unlike DVD+RW, files remain readable even after I/O error reports...

Kernels: 2.6.28.7 and 2.6.28.9

[stern (stern-linux-kernel-bugs)]

I wish I knew of some way to improve the situation, but I don't. It might be a design flaw in all of Samsung's USB interface chips -- possibly also present in devices from other manufacturers, especially if they use interface chips with the same firmware.

[Ka-Hing Cheung (kahing)]

is ehci built-in in jaunty? dmesg says it's using ehci even though I don't see it in lsmod. Anyways, now I can't even workaround by downgrading to usb 1.1

[Peter Hoeg (peterhoeg)]

Yes, it is built in. I believe as a part of the general 'speed up the boot process' work that's taking place.

[Ka-Hing Cheung (kahing)]

What would the workaround be in jaunty then?

[nwadams (nwnadams)]

I have this same problem with hardy.

[ 443.450761] usb 2-1: new high speed USB device using ehci_hcd and address 14
[ 443.495973] usb 2-1: device descriptor read/64, error -71
[ 443.640251] usb 2-1: device descriptor read/64, error -71
[ 443.824952] usb 2-1: new high speed USB device using ehci_hcd and address 15
[ 443.917340] usb 2-1: device descriptor read/64, error -71
[ 444.053715] usb 2-1: device descriptor read/64, error -71
[ 444.162716] usb 2-1: new high speed USB device using ehci_hcd and address 16
[ 444.407338] usb 2-1: device not accepting address 16, error -71
[ 444.495996] usb 2-1: new high speed USB device using ehci_hcd and address 17
[ 444.900206] usb 2-1: device not accepting address 17, error -71

its just this acomdata external hdd that does not work for me. All my other usb sticks work properly.
i can modprobe -r ehci_hcd and it mounts as usb 1.1

However if i plug it in before boot up it mounts properly as usb 2.0

I tested with a jaunty live cd and it mounts as usb 1.1 unless plugged in before boot. And again all my other devices work properly.

let me know if there's any other logs i can post to help.

[Pharazon (pharazon)]

I have this problem with Abit Apollo Pro133x VIA VT82C693A -chipset while trying to plug in a Kingston 16GB Flash Drive. The chipset is supporting only USB 1.1 and using UHCI-HCD -driver. I have also Samsung ML-2010 printer, but it works ok without any problems (whether it's plugged in or out with Kingston Flashdrive. The error message I get while plugging in the flash drive is the following:

[ 935.495973] usb 1-1: device descriptor read/64, error -71
[ 935.640251] usb 1-1: device descriptor read/64, error -71
[ 935.942172] usb 1-1: device not accepting address 9, error -71

etc.

I get the problem with Ubuntu 8.04 default kernels 2.6.24-16-server and 2.6.24-19-server. I also compiled a vanilla kernel 2.6.28.2 from the sources (from kernel.org), but it has exactly the same problem. I've tried the kernel parameter & /sys setting usbcore.autosuspend=-1, but it doesn't work. I also attached the flash drive to an external hub, but it doesn't change the situation compared to plugging it in straight.

So it's not limited to EHCI-HCD, the same problem appears also on UHCI-HCD -driver in the latest kernel.

[rna (rna-horobi)]

I have this problem with Ubuntu 8.04 + GA-MA78GM-S2H (AMD SB700).
This is kernel bug. See bellow.

  Bug 10913 - USB wont work with ehci_hcd on GA-MA78GM-S2H (AMD SB700)
  http://bugzilla.kernel.org/show_bug.cgi?id=10913

Andiry Xu's patch works fine for me.
I wish this patch would be applied to next update.

[uzytkownik2 (uzytkownik2-linux-kernel-bugs)]

I have similar issue with 2.6.29 I hadn't before (in 2.6.28 - however it might be so as modules used to be loaded in incorrect order by udev):
[250625.112100] usb 3-4: reset high speed USB device using ehci_hcd and address 2
[250640.646029] usb 3-4: device not accepting address 2, error -110
[250640.748038] usb 3-4: reset high speed USB device using ehci_hcd and address 2
[250656.288076] usb 3-4: device not accepting address 2, error -110
[250656.390089] usb 3-4: reset high speed USB device using ehci_hcd and address 2
[250666.812036] usb 3-4: device not accepting address 2, error -110
[250666.914045] usb 3-4: reset high speed USB device using ehci_hcd and address 2
[250677.336026] usb 3-4: device not accepting address 2, error -110

It is a single USB stick connected to port. When I'll have free time I'll check a) verbose output b) 2.6.28.

[Hated On Mostly (mostly-hated-on)]

Here is the link to Andiry Xu's patch that rna refers to:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b09bc6cbae4dd3a2d35722668ef2c502a7b8b093

[Oisín Mac Fhearaí (denpashogai)]

2009/5/11 Hated On Mostly <email address hidden>:
> Here is the link to Andiry Xu's patch that rna refers to:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b09bc6cbae4dd3a2d35722668ef2c502a7b8b093

Thanks for the link. Unfortunately this bug doesn't only affect ATI
cards, so I think the patch is too specific to help us all (my mobo is
an Intel job):

"+ case PCI_VENDOR_ID_ATI:"

Unless a more general version of this workaround would solve the problem?

[Hated On Mostly (mostly-hated-on)]

I run an Intel board as well. I am hoping that maybe this bug will get some more attention because of a patch that works for some systems but probably not. A lot of developers feel code review is beneath them, particularly for something they feel they never get wrong.

The guy who is willing to install any version of Ubuntu and let developers remote into his system to observe this bug only got contacted by one person and that guy blew him off saying the bug doesn't exist (without actually remoting into his system).

Remember this bug has been around in the linux world for years and ignored for years . Don't hold your breath about this getting fixed. If developers aren't willing to remote into a system to check it out there is little chance of them caring enough to fix the problem.

[halfmanhalfbug (broose2u)]

I have this exact problem with a particular SATA external hard-drive using kernel 2.6.24 (Hardy) and 2.6.27 (Jaunty). My observation is that plugging in the device with only one USB connection results in the problem (infinite resets) but plugging in the device with 2 connections (1 data+power and 1 power only) results in correct polling and mounting.
I am wondering if the USB 2.0 driver is supposed to sense and allocate power (or more precisely current)? Incorrect powering would explain why the problem is only seen with certain hardware combinations and is especially seen with USB hubs, which split power.

[Arnaud Quette (aquette)]

2009/5/15 halfmanhalfbug

> I have this exact problem with a particular SATA external hard-drive using
> kernel 2.6.24 (Hardy) and 2.6.27 (Jaunty). My observation is that plugging
> in the device with only one USB connection results in the problem (infinite
> resets) but plugging in the device with 2 connections (1 data+power and 1
> power only) results in correct polling and mounting.
> I am wondering if the USB 2.0 driver is supposed to sense and allocate
> power (or more precisely current)? Incorrect powering would explain why the
> problem is only seen with certain hardware combinations and is especially
> seen with USB hubs, which split power.
>

this is not software related, but hardware related here.
these kind of external devs need more power than a single USB connection can
provide.
I've personnaly an external cdrom drive like that.
an "idiot proof" is to run the same dev on another platform. result
guaranteed ;-)

Arnaud

[halfmanhalfbug (broose2u)]

Hmmmm... Windows XP is OK with one connection and USB 1.1 with kernel 2.6.24 works fine with one connection. The same drive mounts fine with one connection and kernel 2.6.27 on a Toshiba Satellite A215 but not with the same kernel on my HP L2000.

[Arnaud Quette (aquette)]

2009/5/16 halfmanhalfbug

> Hmmmm... Windows XP is OK with one connection and USB 1.1 with kernel
> 2.6.24 works fine with one connection. The same drive mounts fine with
> one connection and kernel 2.6.27 on a Toshiba Satellite A215 but not
> with the same kernel on my HP L2000.
>

so it's not the issue I was mentioning (I was too lazy to check the full
thread, sorry), but it seem still related to bus powering and how the driver
handles this...

Arnaud

[andrej (andrej-linux-kernel-bugs)]

I applied the EHCI patch to 2.6.28.9 and the DVD writer worked *fine* since then. There were no device resets and no damaged media. (The OHCI patch was rejected with 2.6.28.9, so I assume it had been merged before that.)

Unfortunately, when I connected an OHCI device (a USB audio adapter) to the same (NEC) host controller as the (Samsung) DVD writer, hundreds of messages like this appeared in dmesg:

sr 10:0:0:0: [sr1] Result: hostbyte=0x05 driverbyte=0x00
end_request: I/O error, dev sr1, sector 6363180
Buffer I/O error on device sr1, logical block 1590795
lost page write due to I/O error on sr1
usb 1-2: reset high speed USB device using ehci_hcd and address 4
usb 1-2: reset high speed USB device using ehci_hcd and address 4
usb 1-2: reset high speed USB device using ehci_hcd and address 4
usb 1-2: reset high speed USB device using ehci_hcd and address 4

When these things happen, both the DVD writer and the audio adapter freeze. Programs like alsamixer or dvd+rw-mediainfo remain blocked in an uninterruptible state. Unloading and re-loading both ohci_hcd and ehci_hcd does not help. The devices have to be reconnected physically.

All the problems seem to start with this message:

ohci_hcd 0000:01:05.0: bad entry 20d00

After the message, the sound card stops responding and the DVD writer has only a few seconds left before the never-ending series of device resets begins.

BTW, lsusb freezes as well. (Haven't seen that before.) It surprises me that one misbehaving device (which is probably the Samsung drive) has such an impact on the whole host controller.

[btanoue (btanoue)]

Greetings Everybody,

I recently found a new work-around that works for my system. I stumbled on this by accident. I ran out of USB ports on my desktop box, and purchased a CyberPower (Powered USB Hub) off Buy.com.

I then thought, I should try the powered USB drive that was giving me a headache under Intrepid and Jaunty. Low and Behold, I was able to now transfer 27 GB's with out a hiccup at USB 2.0 speeds. I was hitting about 20+ MB/s write.

Here is the model number of the hub:
CP-H720P

I'm thinking its a cheap and easy solution while waiting for a bug fix in the kernel.

Good Luck and YMMV
btanoue

[Perry E. Metzger (perry-piermont)]

btanoue <email address hidden> writes:
> I recently found a new work-around that works for my system. I stumbled
> on this by accident. I ran out of USB ports on my desktop box, and
> purchased a CyberPower (Powered USB Hub) off Buy.com.

This is not a new work around. There are others earlier in the error
history who note that this can work.

> I'm thinking its a cheap and easy solution while waiting for a bug fix
> in the kernel.

After all these years, one has serious doubts that anyone cares enough
to fix the problem.

Perry

[Stefano_PG (slot)]

Today I noticed that my VIA based PCI controller seems to be affected by this bug too. It always runs well, but if I plug more than one device the controller resets.

[Perry E. Metzger (perry-piermont)]

Stefano_PG <email address hidden> writes:
> Today I noticed that my VIA based PCI controller seems to be affected by
> this bug too. It always runs well, but if I plug more than one device
> the controller resets.

That's not the same bug.

Perry

[Stefano_PG (slot)]

Maybe it is: if you read all the posts you will find USB devices resetting when plugged directly, others when plugged by an hub, others working only sometimes. The only point that is the same is that it happens only with ehci_hcd and it doesn't with USB 1.1.

[Perry E. Metzger (perry-piermont)]

Stefano_PG <email address hidden> writes:
> Maybe it is: if you read all the posts you will find USB devices

Maybe doesn't work really well when you're diagnosing a bug. There isn't
an a priori reason to expect these are the same problem.

One of the issues with this bug report has been that everyone with a USB
problem has tossed in a report onto this -- there's a massive smog that
makes it hard for people to figure out what is actually going on.

Perry
--
Perry E. Metzger <email address hidden>

[falk (falk-efalk)]

> After all these years, one has serious doubts that anyone cares enough
> to fix the problem.

Is anybody working on it? If so, I would be happy to let them log into my system to see the problem for themselves. 2.6.24-24-386 kernel. Ubuntu 8.04.2. Contact me at <email address hidden>

[kernel.org (kernel.org-linux-kernel-bugs)]

I have been experiencing similar issues to what is described here, however it involves keyboard and mouse on ubuntu with their kernel 2.6.29. I understand this is not your vanilla kernel, and it's not involving the same type of devices as reported initially here. However please bear with me and read on.

First I'd like to bring your attention to the fact there has been many similar bug reports about usb resets on various distro, a few examples are:
https://bugs.launchpad.net/bugs/124406 : the resets affects keyboard and mouse
https://bugs.launchpad.net/bugs/91230 : idem, just older
http://<email address hidden>/msg18199.html
http://taint.org/2006/12/13/191554a.html
http://bugs.gentoo.org/177266
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/54419
...
There's plenty more if you search the net with these keywords: reset speed USB device using ehci_hcd.

I believe it's a long standing bug which is elusive and difficult to track. What I observe across a lot of reports is often the following:

- It gets dismissed by being hardware related. Certainly some of these reports are due to bad hardware. However there are many cases where the same config works perfectly well with other non-linux OS.

- It's often resolved by trying to connect the affected devices differently. In my case it seems I had to put my external keyboard and mouse to a separate hub.

- Many people are getting frustrated with it and either give up or play around like me. I gave up on migrating to linux a couple years ago because of this bug.

Being so elusive and widespread, many of these bug reports end up with either no fix, or a workaround like mentioned before that does not really address the issue. And since nobody can do much about it, these reports become inactive/closed. One of the most active thread on this bug (first link I gave above) is probably going to end up being closed because it has been judged too "messy" (I agree but that's no reason to close it, it's just a messy bug).

One might argue there are more than one bug here, because different devices are affected. My guess however is that it's one bug affecting various devices (hd, kb, mice, ...). In fact, having played around a bit, I would advance the theory that it is related to the presence of devices with different speed on the same bus/hub (lo+hi and lo+full for sure, hi+lo most likely). If you look at this post, you'll see a report of this bug on a usb 1.1 machine:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/254

So it could be (pure speculation) that this bug has been introduced since the addition of ehci, and is affecting usb1.1 as a result of the changes made to accomodate ehci. According to http://www.mjmwired.net/kernel/Documentation/usb/ehci.txt :
Note that USB 2.0 support involves more than just EHCI. It requires other changes to the Linux-USB core APIs, including the hub driver, but those changes haven't needed to really change the basic "usbcore" APIs exposed to USB device drivers.

Anyway, my point really is this: this bug is probably more widespread than one can imagine, it affects many distro, it's been reported many t...

[stern (stern-linux-kernel-bugs)]

It's quite possible that this problem is caused by a bug in the Clear-TT-Buffer handling in ehci-hcd. This was brought to my attention just recently, and I wrote a pair of patches to fix it. They have not yet been submitted, but you (or anyone else reading this bug report) can test them.

I'll attach them to the bug report. They are against 2.6.30-rc6 but they probably will apply to earlier kernel versions too. You'll need to use both patches, in order.

[stern (stern-linux-kernel-bugs)]

Created attachment 21743
Add Clear-TT-Buffer callback

Patch 1: modify the Clear-TT-Buffer interface by adding a callback pointer

[stern (stern-linux-kernel-bugs)]

Created attachment 21744
Make ehci-hcd wait for Clear-TT-Buffer to complete

Patch 2: Make ehci-hcd wait Clear-TT-Buffer requests to complete

[lvm (lvm-royal)]

Same problem here with hardy, alcor and nforce430.

2.6.24-24-generic #1 SMP Wed Apr 15 15:11:35 UTC 2009 x86_64 GNU/Linux

$ lspci|grep -i usb
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)

$ lsusb
Bus 002 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 012: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)
Bus 001 Device 001: ID 0000:0000

# grep -i usb <dmesg
[ 93.997664] usbcore: registered new interface driver usbfs
[ 93.997691] usbcore: registered new interface driver hub
[ 93.997725] usbcore: registered new device driver usb
[ 94.000699] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
[ 94.003812] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[ 94.014663] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[ 94.014807] usb usb1: configuration #1 chosen from 1 choice
[ 94.014834] hub 1-0:1.0: USB hub found
[ 94.119479] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
[ 94.178035] usb usb2: configuration #1 chosen from 1 choice
[ 94.178067] hub 2-0:1.0: USB hub found
[ 94.574386] usb 1-9: new high speed USB device using ehci_hcd and address 3
[ 94.704594] usb 1-9: configuration #1 chosen from 1 choice
[ 95.005899] usb 2-3: new low speed USB device using ohci_hcd and address 2
[ 95.230333] usb 2-3: configuration #1 chosen from 1 choice
[ 95.237653] usbcore: registered new interface driver libusual
[ 95.242915] Initializing USB Mass Storage driver...
[ 95.243006] scsi2 : SCSI emulation for USB Mass Storage devices
[ 95.243082] usbcore: registered new interface driver usb-storage
[ 95.243086] USB Mass Storage support registered.
[ 95.243253] usb-storage: device found at 3
[ 95.243256] usb-storage: waiting for device to settle before scanning
[ 95.249629] usbcore: registered new interface driver hiddev
[ 96.669636] hiddev96hidraw0: USB HID v1.10 Device [American Power Conversion Smart-UPS 1000 FW:652.18.I USB FW:7.3] on usb-0000:00:02.0-3
[ 96.669657] usbcore: registered new interface driver usbhid
[ 96.669662] /build/buildd/linux-2.6.24/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[ 100.238536] usb-storage: device scan complete
[ 100.239143] scsi 2:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0
[ 100.239635] scsi 2:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0
[ 100.240134] scsi 2:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0
[ 100.240632] scsi 2:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0

and then the fun starts (no usb activity on bus 1 at this time)

Jun 13 12:07:23 server kernel: [523139.052749] usb 1-9: reset high speed USB device using ehci_hcd and address 12
Jun 13 12:09:27 server kernel: [523206.095530] usb 1-9: reset high speed USB device using ehci_hcd and address 12
Jun 13 12:10:18 server kernel: [523228.260320] usb 1-9: reset high speed USB device using ehci_hcd and...

[Stefano_PG (slot)]

Maybe this bug will be fixed when we will all use USB 3.0 devices. With another driver, of course.

@Perry: I started using only one device for each USB contoller but the 2.0 ones still reset with similar warnings, so I think that my nforce2 chipset and my PCI bridged VIA 6212 are both affected by this bug.
I've checked both my USB drive and my USB bluetooth dongle... I don't have other USB devices

[markofealing (mark-ferns16)]

I really can't believe that this has not been fixed, I mean USB 2.0 is THE way of connecting devices to PCs these days.

Come on guys, sort out your priorities. It's stupid bugs like this which return Ubuntu users back to the "dark side". If Linux is every to gain market share then this sort of bug really needs to be fixed quickly, and that means with six months, not two plus years (and still waiting)!!

No impressed at all.

[chiacchio (chiacchio)]

I agree with you Marko. You expressed exactly what I think...

2009/7/28 markofealing <email address hidden>

> I really can't believe that this has not been fixed, I mean USB 2.0 is
> THE way of connecting devices to PCs these days.
>
> Come on guys, sort out your priorities. It's stupid bugs like this which
> return Ubuntu users back to the "dark side". If Linux is every to gain
> market share then this sort of bug really needs to be fixed quickly, and
> that means with six months, not two plus years (and still waiting)!!
>
> No impressed at all.
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Perry E. Metzger (perry-piermont)]

chiacchio <email address hidden> writes:
> 2009/7/28 markofealing <email address hidden>
>> I really can't believe that this has not been fixed, I mean USB 2.0 is
>> THE way of connecting devices to PCs these days.
>>
>> Come on guys, sort out your priorities. It's stupid bugs like this which
>> return Ubuntu users back to the "dark side". If Linux is every to gain
>> market share then this sort of bug really needs to be fixed quickly, and
>> that means with six months, not two plus years (and still waiting)!!
>
> I agree with you Marko. You expressed exactly what I think...

I've been saying this for a long time, but it seems like the concern
level among those in a position to work on this is limited.

Perry

[Mike.lifeguard (mikelifeguard)]

This bug report, and comments on it, are for solving a technical issue. If your comment doesn't directly further that goal, then it doesn't belong here. Please note that every "me too" and "why isn't this fixed yet" spams many people's inboxes with these useless messages. If you have something constructive to say, feel free, but otherwise it is needless noise. Thanks.

[Offtopic (usednick)]

Deactivating USB keyboard support on the BIOS seems to have fixed the problem on my Gigabyte MA69GM-S2H (AMD 690G chipset).

I have been using USB 2.0 devices (at around 11 MB/s) ever since without a problem nor a reset so far (around 5 weeks now).

The only problem introduced by this solution is that I can't use my usb keyboard to select which partition to boot from on the grub menu.

Tested on debian squeeze and ubuntu hardy.

Francisco.

[Perry E. Metzger (perry-piermont)]

"Mike.lifeguard" <email address hidden> writes:
> This bug report, and comments on it, are for solving a technical issue.
> If your comment doesn't directly further that goal, then it doesn't
> belong here.

It does further the goal -- it makes people aware of the fact that a
critical bug has been left untouched for years.

> Please note that every "me too" and "why isn't this fixed
> yet" spams many people's inboxes with these useless messages.

They're only useless if you believe the problem should be ignored.

Perry
--
Perry E. Metzger <email address hidden>

[Forest Bond (forest-bond)]

Hi Jirka,

On Fri, Jul 31, 2009 at 09:49:38AM -0000, Jirka Vilim wrote:
> ** Changed in: linux (Ubuntu Jaunty)
> Status: In Progress => Fix Committed

Fix committed? Can you provide any information about the fix?

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[Lukáš Chmela (lukaschmela)]

Forest Bond píše v Pá 31. 07. 2009 v 12:28 +0000:
> Hi Jirka,
>
> On Fri, Jul 31, 2009 at 09:49:38AM -0000, Jirka Vilim wrote:
> > ** Changed in: linux (Ubuntu Jaunty)
> > Status: In Progress => Fix Committed
>
> Fix committed? Can you provide any information about the fix?
>
> Thanks,
> Forest
> --
> Forest Bond
> http://www.alittletooquiet.net
> http://www.pytagsfs.org
>

Well, I spoke to Jirka and he said it was just a mistake when he was
finding solution to his problem.

I'll revert the change back.

--
Lukáš Chmela <email address hidden>
IRC: <email address hidden>, ICQ: 202077459
514D 3C69 8498 E400 0ACE 90F2 00E3 CACA A5BA ECC7

[nwadams (nwnadams)]

interesting note though. I tried karmic alpha 3 and it fixes all my
usb problems. tested the live cd quite extensively.

2009/7/31 Lukáš Chmela <email address hidden>:
> Forest Bond píše v Pá 31. 07. 2009 v 12:28 +0000:
>> Hi Jirka,
>>
>> On Fri, Jul 31, 2009 at 09:49:38AM -0000, Jirka Vilim wrote:
>> > ** Changed in: linux (Ubuntu Jaunty)
>> >        Status: In Progress => Fix Committed
>>
>> Fix committed?  Can you provide any information about the fix?
>>
>> Thanks,
>> Forest
>> --
>> Forest Bond
>> http://www.alittletooquiet.net
>> http://www.pytagsfs.org
>>
>
> Well, I spoke to Jirka and he said it was just a mistake when he was
> finding solution to his problem.
>
> I'll revert the change back.
>
> --
> Lukáš Chmela <email address hidden>
> IRC: <email address hidden>, ICQ: 202077459
> 514D 3C69 8498 E400 0ACE  90F2 00E3 CACA A5BA ECC7
>
>
> ** Changed in: linux (Ubuntu Jaunty)
>       Status: Fix Committed => In Progress
>
> --
> ehci_hcd module causes I/O errors in USB 2.0 devices
> https://bugs.launchpad.net/bugs/88746
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Confirmed
> Status in “linux” package in Ubuntu: In Progress
> Status in “linux-source-2.6.20” package in Ubuntu: Won't Fix
> Status in “linux-source-2.6.22” package in Ubuntu: Won't Fix
> Status in linux in Ubuntu Hardy: Confirmed
> Status in linux-source-2.6.20 in Ubuntu Hardy: Won't Fix
> Status in linux-source-2.6.22 in Ubuntu Hardy: Won't Fix
> Status in linux in Ubuntu Intrepid: Confirmed
> Status in linux-source-2.6.20 in Ubuntu Intrepid: Won't Fix
> Status in linux-source-2.6.22 in Ubuntu Intrepid: Won't Fix
> Status in linux in Ubuntu Jaunty: In Progress
> Status in linux-source-2.6.20 in Ubuntu Jaunty: Won't Fix
> Status in linux-source-2.6.22 in Ubuntu Jaunty: Won't Fix
> Status in “linux-source-2.6.22” package in Baltix: Invalid
> Status in “linux” package in Fedora: Invalid
>
> Bug description:
> Certain USB devices do not work properly, or do not work at all, while the ehci_hcd module is loaded.
>
> A solution is to unload the ehci_hcd module, which is loaded every time the computer starts, using the command 'sudo modprobe -r ehci_hcd'. This works fine but unfortunatly ehci-hcd is necessary for using USB 2.0, so you lose USB 2.0 features.
> Another solution is to disable USB 2.0 through the BIOS setup.
>
> With some devices it is possible to read files normally (ie. copy files from an USB pendrive to the computer), but the device disconnects abrubtly when you start writing data on the device. In some devices it fails after writing a certain amount of data, probably the size of the write cache.
>
> Steps to reproduce:
> 1. Insert your USB 2.0 device (like a flash drive)
> 2. If the device is recognised and mounted properly try copying a file to it.
> 3. Comfirm with the 'dmesg' command that it isn't functioning properly. (I/O errors etc)
> 4. Remove the USB device
> 5. Unload ehci_hcd with  'sudo modprobe -r ehci_hcd'
> 6. Insert your USB device again.
> 7. Check that everything works. (copy some files, etc.)
>
> A disproportionate number of individuals report Alcor chipsets in ...

[cagnulein (cagnulein-linux-kernel-bugs)]

i've the same issue. i'll try the patches ASAP.
thanks

[cagnulein (cagnulein-linux-kernel-bugs)]

i've tried them.
After 300mb of data movement i've see a "reset high speed" :( but it occurs only time...so i think i could say the patches fixed something but not all...i've tried on 2.6.30.2

If i could help let me know :)

[stern (stern-linux-kernel-bugs)]

Can you reproduce the reset? If you can't, then there's nothing to worry about. If you can, attach a usbmon log showing what happens starting shortly before the reset.

[cagnulein (cagnulein-linux-kernel-bugs)]

ok, i'll try it. Thanks for your work :)

[cagnulein (cagnulein-linux-kernel-bugs)]

i've created this file with usbmon during a moving the directory /usr/ on my ssd
after 40mb it gives me a reset
i've pressed CTRL-C ASAP i've seen the reset
i hope it can help you

here is the log: http://www.cagnulein.com/tmp/usbmon_ehci_reset.txt

[stern (stern-linux-kernel-bugs)]

Unfortunately the usbmon log doesn't show why the reset occurred. Apparently the computer was writing data to the disk when the disk suddenly stopped accepting data. After 30 seconds the computer gave up and and reset the disk drive, after which it started working normally again.

[cagnulein (cagnulein-linux-kernel-bugs)]

could it be an hardware problem? how can i verify this?

[stern (stern-linux-kernel-bugs)]

Sure it could. Verify it by trying out different hardware.

[kernel.org (kernel.org-linux-kernel-bugs)]

Also try a different cable.
And last but not least: try another non-linux OS (but don't ask me for suggestion;)

[andrej (andrej-linux-kernel-bugs)]

Most of these weird problems seem to occur if (and only if) I use a PCI USB controller plugged into a PCI-X slot of my IBM xSeries server.

Some facts:
* Tried two USB controllers, NEC and VIA.
* NEC works fine when only one mass storage device is plugged in. Resets occur otherwise.
* NEC doesn't like webcams. The image is either choppy or just black, varies from (kernel) version to version.
* VIA doesn't support mass storage at all. Numerous I/O errors pop up immediately when a device is connected.
* VIA supports webcams, but only at UHCI speeds. When a EHCI-only webcam is plugged in, it is detected, but doesn't work.

But here comes the most important fact of all: There are *no* such problems on other Linux machines I run. For example, USB now works fine on my laptop. I can connect my DVB-T receiver, pen drive, bluetooth dongle, webcam and other crazy devices at once and nothing bad happens.

Perhaps there's something wrong with PCI USB controllers in PCI-X slots. Unfortunately, the server is in use, so I can't bring it down and test USB thoroughly.

[cagnulein (cagnulein-linux-kernel-bugs)]

i've try the usb on another pc and works well.
so i've installed windows xp on the pc that has the problem.
TADAM: the problem still remains!

So it's an hardware issue :(

Thanks for your time

[stern (stern-linux-kernel-bugs)]

Greg, I don't think this bug report is helping anybody any more. We haven't heard anything from the OP in almost a year. You might as well close it out.

[greg (greg-linux-kernel-bugs)]

Ok, closing out, thanks.

[kernel.org (kernel.org-linux-kernel-bugs)]

I find the decision to close this bug quick and unfounded. Who has verified that the fix committed earlier has resolved this issue? It's not because the last person talking here said it was hardware-related that there was no bug. Ideally we should find a machine/configuration where this bug has happened, test without the fix, test with the fix, and then conclude.

Please read my comment #67 above. This bug has been occuring regularly and people report it mostly against distros bug tracking. Since distro can't do much they often close the report because they find it hard to track and do anything about it. This practice of closing bug because they're too elusive to track isn't right, even less in open source (what's the problem with how long a bug is open?)

[greg (greg-linux-kernel-bugs)]

(In reply to comment #84)
> I find the decision to close this bug quick and unfounded. Who has verified
> that the fix committed earlier has resolved this issue?

I did not see any reports of this problem with the latest Linux kernel.

If you do have this problem, with the 2.6.30 or later kernel, please post to the <email address hidden> mailing list the kernel log messages and we will be glad to work with you there.

[stern (stern-linux-kernel-bugs)]

(In reply to comment #84)
> I find the decision to close this bug quick and unfounded.

The bug report was opened more than a year ago. How can you call that "quick"?

Evidently you did not receive the message I sent to you in response to comment #67. The gist of it was that this is not a single bug. Most of the bug reports you cited were either non-reproducible or caused by hardware problems. In others the reporters have stopped responding, making it impossible to find out what was wrong.

So far there has been extremely little indication that errors in the software are responsible for these resets. Even if it is true that the software is partly to blame, we have no way to fix it unless we can find out exactly where the errors are. Errors get fixed when they are tracked down, and your rant doesn't contribute towards tracking down any of these problems.

[kernel.org (kernel.org-linux-kernel-bugs)]

(In reply to comment #86)
> (In reply to comment #84)
> > I find the decision to close this bug quick and unfounded.
> The bug report was opened more than a year ago. How can you call that
> "quick"?
I say quick as in quick-thinking.

> Evidently you did not receive the message I sent to you in response to
> comment #67. The gist of it was that this is not a single bug.
I did receive it, but I was just starting out with linux and couldn't really deal with kernel hacking, I needed to get going with my work.
> Most of the bug reports you cited were either non-reproducible or caused by
> hardware problems.
> In others the reporters have stopped responding, making it impossible to find
> out what was wrong.
That's what I call hard to track and elusive. Does that mean there's no bug? No. If there's a bug, even if hard to track, I think there should be an entry for it. All this talk about keeping a log only for reproducible bugs does not make sense to me, and only reflect a dislike for unreproducible bug.

> So far there has been extremely little indication that errors in the software
> are responsible for these resets.
How do you explain other OS had no issue in the same configuration?

> Even if it is true that the software is
> partly to blame, we have no way to fix it unless we can find out exactly
> where
> the errors are. Errors get fixed when they are tracked down, and your rant
> doesn't contribute towards tracking down any of these problems.
Closing this bug doesn't contribute in nailing it down. That's what happened for the last two years: it gets reported and then closed, it reappers somewhere else but the OP quickly disappears because this bug is a showstopper (you can't work with it).

Anyway, there's no need to consider this a rant and get personal about it. I appreciate a lot all the efforts from the so many people in getting GNU/Linux to where it is now. Also, bear in mind that in the past 4 years I really wanted to get away from M$. This bug kept me from making the move. Only recently did I try again, got this bug again, but did not want to get discouraged because of it. So I'm sorry for making so much noise, I'm tired of this bug as much as you are, but I don't want to forget about it.

Is the fix you talked about in 2.6.30? If so then it should be in my arch release kernel. I'll rewire my devices (in order to reproduce the bug) and report back in about a week when I have more time to play.

[stern (stern-linux-kernel-bugs)]

> That's what I call hard to track and elusive. Does that mean there's no bug?
> No. If there's a bug, even if hard to track, I think there should be an entry
> for it. All this talk about keeping a log only for reproducible bugs does not
> make sense to me, and only reflect a dislike for unreproducible bug.

If a bug isn't reproducible and can't be tracked then there is no hope of fixing it. In such cases, whether the bug report remains open or not doesn't really matter much.

> How do you explain other OS had no issue in the same configuration?

I can't explain it because I haven't been able to obtain enough information. Mostly this is because the reporters stop responding, but occasionally it's because special debugging hardware is needed and the reporter doesn't have it.

One possible explanation might be that the drivers for the other OS were written with special knowledge of some bugs in the hardware. Manufacturers often don't share such knowledge with open-source programmers. But I have no way to know if this is the case here.

> Closing this bug doesn't contribute in nailing it down. That's what happened
> for the last two years: it gets reported and then closed, it reappers
> somewhere
> else but the OP quickly disappears because this bug is a showstopper (you
> can't
> work with it).

You are making a very common mistake: confusing the bug with the bug report. I keep telling you that what we see reported here, in this one report, is really many different bugs. Several of them have already been tracked down and solved. You don't seem to understand this.

> Only recently did I
> try again, got this bug again, but did not want to get discouraged because of
> it. So I'm sorry for making so much noise, I'm tired of this bug as much as
> you
> are, but I don't want to forget about it.

If you would like to contribute, please open a new bug report. This is because your problem is almost certainly caused by a different bug from the one that originally led to this report.

> Is the fix you talked about in 2.6.30?

Only partially. The most recent code is available in 2.26.31-rc5 together with this patch: <http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch>.

[kernel.org (kernel.org-linux-kernel-bugs)]

I will wait for 2.6.31 to reach arch release then. I'll test before the new kernel, and then after. If the bug is still there, I'd be happy to help with the tracking, but I won't have time to deal with kernel hacking. I'd be happy to use whatever debug kernel that will work on my arch system if one cares to provide it.

I'll open a new bug report if needed and back link to this one because even if there are other bugs that got mingled, I find that most of the discussion here relates to the resets I experience with my keyboard and mouse.

[MDZ (mdz-dzmuran)]

This may be a useful piece of information.

I am using Ubuntu 9.04. My 16GB flash disk sometimes works and sometimes does not. I can see some rules in the behavior, but getting exact results is time consuming.

I can use Low Level Format utility (http://hddguru.com) to reformat the flash disk in Windows. I can then create a new partition and volume on it using either gparted or Windows tools. The flash disk normally works in Ubuntu as fas as I don not store a lot of data on it. Then it stops working and I am getting the messages above.
I am not quite sure what "a lot of data" means. It may be more then 4GB of data, or a lot of files on the disk in total number, but it is not 255 files in a single directory. It does not matter if I store the data on the disk using Ubuntu or Windows. BUT, if I use Ubuntu to store the data, is works perfectly until I remove the disk from the port. Then, when I attach it to the port againg, it is not recognized anymore.

[stern (stern-linux-kernel-bugs)]

Okay, good. Mostly what I object to is people jumping on board someone else's bug report, with their own bugs that are quite different from the one originally reported, merely because one of the symptoms is the same.

[kernel.org (kernel.org-linux-kernel-bugs)]

I came here because my mouse and keyboard become unusable (jumpy mouse, repeating keys) in various settings (tried 2 different hubs and different cables) and each time dmesg shows that keyboard and/or mouse get reset. Earlier in the thread keyboard and mouse were mentioned as well as resets so I thought it was a good place here.

Initially I reported my issue against ubuntu bug 124406 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406?comments=all). However this bug got closed because it was judged too messy. I felt this bug did not get the proper attention it deserved, so I came here because I thought the kernel team would be more able to deal with it. I entered comment #67 and also created another ubuntu bug entry (see https://bugs.launchpad.net/ubuntu/+bug/383722). There you'll find more info on what I experience along with relevant dmesg logs.

I understand your point except that in practice when a bug is difficult to track and reproduce it gets reported in many different ways, and there's not much we can do about that. I'm sorry to be so forthcoming but I'm tired of always seeing this bug getting dismissed in similar ways: can't reproduce, OP gone, confusion with other bugs... If we keep sticking to the rules of clean and reproducible bugs then we'll never become good at dealing with concurrency issues and parallel computing!

BTW: I can reproduce the bug and so does Rolf Leggewie (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/254).

[stern (stern-linux-kernel-bugs)]

All right. We'll wait until you can install the latest kernel with all the existing patches and are able to do some testing. You will need to enable CONFIG_USB_DEBUG, CONFIG_USB_MON, and CONFIG_DEBUG_FS.

[uzytkownik2 (uzytkownik2-linux-kernel-bugs)]

I'm thinking I've spot the particular USB configuration when the problem is present. It seems to be when copied large amount of data (say 1.9 GiB) from USB using SD-card reader. I've not check this time but it seems that it does not occure on dd of partition.

Reproduced on 2.6.30.4 - I'll check the -rc soon.

[Marcelo R. Minholi (minholi)]

This is happening here too. I'm with Jaunty and using kernel 2.6.28-15 from jaunty-proposed. There is some usb bugfixes on it, but also did not solve this problem.

My laptop is an Acer 5100-5196

$ lsusb
Bus 001 Device 004: ID 152d:2339 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 001 Device 002: ID 5986:0100 Acer, Inc OrbiCam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 15d9:0a33
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

JMicron is my external HDD enclosure (Satellite AX-323)

$ lspci |grep USB
00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80)
00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80)
00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80)

Now it's correctly detected, but after some time I get I/O errors and the device is re-connected through ohci_hcd

[Andy Rabagliati (andyr)]

I have found that most of my problems have cleared up by doing the following :-

1. Adding the following to /etc/initramfs-tools/modules :-

ohci_hcd
ehci_hcd

2. Rebuilding the initramfs by running 'update-initramfs'

3. Reboot.

This (I believe) ensures the modules are loaded in the right order at boot.

[rna (rna-horobi)]

#520 Oisín Mac Fhearaí wrote on 2009-05-11:
> Thanks for the link. Unfortunately this bug doesn't only affect ATI
> cards, so I think the patch is too specific to help us all (my mobo is
> an Intel job):
>
> "+ case PCI_VENDOR_ID_ATI:"
>
> Unless a more general version of this workaround would solve the problem?

This is a bug of chipset. Maybe, there's no 'general version'
workaround.

It seems Bug #88746 is a complex of problems such as SB600/700
problem, so we need to apply many workarounds to fix...

Andiry Xu's patch and Shane Huang's patch (which extends Xu's patch
for SB600) are merged to linux-2.6.28, and are inherited by 2.6.31.
In fact, these patches are already applied to Ubuntu 9.04's kernel
image.

These patches are considered to be necessery and effective, so there's
no reason to reject these patches for 8.04 kernel image.

Apply these patches please!

USB: fix SB700 usb subsystem hang bug
Andiry Xu [Fri, 14 Nov 2008 03:42:29 +0000 (11:42 +0800)]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commitdiff;h=b09bc6cbae4dd3a2d35722668ef2c502a7b8b093

USB: fix SB600 USB subsystem hang bug
Shane Huang [Tue, 25 Nov 2008 07:12:33 +0000 (15:12 +0800)]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=commitdiff;h=0a99e8ac430a27825bd055719765fd0d65cd797f

[Perry E. Metzger (perry-piermont)]

rna <email address hidden> writes:
> This is a bug of chipset.

No it isn't. Other operating systems don't have the problem.

Perry

[Marcelo R. Minholi (minholi)]

Kernel 2.6.31 solved my problem.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/

[rna (rna-horobi)]

Perry E. Metzger wrote on 2009-09-14:
> No it isn't. Other operating systems don't have the problem.

Chip has bug, but the workaround there, the patch said.

> /* SB600 and old version of SB700 have a bug in EHCI controller,
> * which causes usb devices lose response in some cases.
> */
  ...
> ehci_info(ehci, "applying AMD SB600/SB700 USB "
> "freeze workaround\n");

Maybe, other OS's drivers implement the same workaround.

[Perry E. Metzger (perry-piermont)]

rna <email address hidden> writes:
> Perry E. Metzger wrote on 2009-09-14:
>> No it isn't. Other operating systems don't have the problem.
>
> Chip has bug, but the workaround there, the patch said.

Whether other OSes have workarounds or whether the bug is purely in the
software, the effect on the end user is the same, and it is unreasonable
to tell the user that it is their problem.

Perry

[Stefano_PG (slot)]

I'm testing the 2.6.31. Till now (2GB of video in and out) it's all ok.

[TDB (michael-baranov)]

> Kernel 2.6.31 solved my problem.
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/
Confirming it, kernel 2.6.31 solved the problem for me too.

[Stefano_PG (slot)]

After some file transferring, daily use as host of a thunderbird profile, some videos seen and a partition format mi USB 2.0 disk is still working like a charm. This with the chipset VIA VT6214 PCI bridged.

I'm now testing the Nvidia nForce2 integrated in the motherboard.

[Stefano_PG (slot)]

Although the transfer rate is very low: about 6 MB/s with the VIA VT, about 4.5 MB/s with the nvidia nForce2

[Mike Berkley (mike-berkley)]

Just purchased a new Shuttle PC, SA76G2 with an AMD 760G chipset. Tried to boot from an Ubuntu 9.04 USB stick. Failed. Tried to boot from a USB CDROM with a 9.04.2 CD. Failed.

Finally, I went into the BIOS, set it to have "All of USB device operated on full/low speed mode" (quote from the manual).

USB stick booted first time, and I was able to install Ubuntu without errors. It was slow, but no errors.

This bug with high speed USB storage devices is a big issue. If I was not an expert and hadn't known about the bug, I don't know how long it would have taken to diagnose this install problem.

[Stefano_PG (slot)]

The Jaunty CD should carry the 2.6.28. Karmic will use the 2.6.31, so
you should be able to install it from the pendrive.
My Usb HD is still working, it's slow but funcional. I'm crossing every
finger I can.

Il 25/09/2009 17:04, Mike Berkley ha scritto:
> Just purchased a new Shuttle PC, SA76G2 with an AMD 760G chipset. Tried
> to boot from an Ubuntu 9.04 USB stick. Failed. Tried to boot from a USB
> CDROM with a 9.04.2 CD. Failed.
>
> Finally, I went into the BIOS, set it to have "All of USB device
> operated on full/low speed mode" (quote from the manual).
>
> USB stick booted first time, and I was able to install Ubuntu without
> errors. It was slow, but no errors.
>
> This bug with high speed USB storage devices is a big issue. If I was
> not an expert and hadn't known about the bug, I don't know how long it
> would have taken to diagnose this install problem.
>
>

[Andreas Ermler (aermler)]

Using Kernel Version 2.6.31 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/ did not solve the problem for me.
 I still get these:
[ 631.112050] usb 1-8: reset high speed USB device using ehci_hcd and address 2
..and also a lot of other weird output that I haven't seen before, here is all of it:
http://paste.ubuntu.com/278271/

[Stefano_PG (slot)]

Which chipset are you using?
What is the transfer rate value when the devices are working (if they)?

Il 25/09/2009 23:59, Andreas Ermler ha scritto:
> Using Kernel Version 2.6.31 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/ did not solve the problem for me.
> I still get these:
> [ 631.112050] usb 1-8: reset high speed USB device using ehci_hcd and address 2
> .and also a lot of other weird output that I haven't seen before, here is all of it:
> http://paste.ubuntu.com/278271/
>
>

[Lukáš Chmela (lukaschmela)]

Andreas Ermler píše v Pá 25. 09. 2009 v 21:59 +0000:
> Using Kernel Version 2.6.31 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.31/ did not solve the problem for me.
> I still get these:
> [ 631.112050] usb 1-8: reset high speed USB device using ehci_hcd and address 2
> ..and also a lot of other weird output that I haven't seen before, here is all of it:
> http://paste.ubuntu.com/278271/
>

For me, neither the new kernel doesn't work and my usb 2.0 card reader
keeps resetting with SDHC card in it (it works and worked fine with
MemoryStick.. I don't have any other card to test), although it works
fine in windows.

I have VIA VT8237 chipset.
--
Lukáš Chmela <email address hidden>
IRC: <email address hidden>, ICQ: 202077459
514D 3C69 8498 E400 0ACE 90F2 00E3 CACA A5BA ECC7

[Hated On Mostly (mostly-hated-on)]

Bug still present in 2.6.31 kernel:

http://ubuntuforums.org/showpost.php?p=8102459&postcount=142

"I use ubuntu 9.10 on earlier kernels I had no problems after the upgrade but they were gone after sypalo

Linux bum-laptop 2.6.31-14-generic #46-Ubuntu SMP Tue Oct 13 16:47:59 UTC 2009 i686 GNU/Linux

[ 1237.548049] usb 1-2: new high speed USB device using ehci_hcd and address 3
[ 1237.696079] hub 1-0:1.0: unable to enumerate USB device on port 2
[ 1239.357062] usb 1-2: new high speed USB device using ehci_hcd and address 4
[ 1239.490288] usb 1-2: configuration #1 chosen from 1 choice
[ 1239.586860] Initializing USB Mass Storage driver...
[ 1239.588588] scsi6 : SCSI emulation for USB Mass Storage devices
[ 1239.588863] usb-storage: device found at 4
[ 1239.588872] usb-storage: waiting for device to settle before scanning
[ 1239.588898] usbcore: registered new interface driver usb-storage
[ 1239.588908] USB Mass Storage support registered.
[ 1244.585060] usb-storage: device scan complete
[ 1251.245213] gvfsd-metadata[14843]: segfault at 8 ip 0804d2ea sp bff6edf0 error 4 in gvfsd-metadata[8048000+c000]
[ 1266.113051] usb 1-2: reset high speed USB device using ehci_hcd and address 4
[ 1266.436046] usb 1-2: reset high speed USB device using ehci_hcd and address 4
[ 1272.769054] usb 1-2: reset high speed USB device using ehci_hcd and address 4
[ 1273.105067] usb 1-2: reset high speed USB device using ehci_hcd and address 4
[ 1273.445079] usb 1-2: reset high speed USB device using ehci_hcd and address 4
[ 1273.644447] scsi 6:0:0:0: Device offlined - not ready after error recovery"

[Stefano_PG (slot)]

What is a "sypalo"?

and which chipset is this guy using?

Il 14/10/2009 18:16, Hated On Mostly ha scritto:
> Bug still present in 2.6.31 kernel:
>
> http://ubuntuforums.org/showpost.php?p=8102459&postcount=142
>
> "I use ubuntu 9.10 on earlier kernels I had no problems after the
> upgrade but they were gone after sypalo
>
> Linux bum-laptop 2.6.31-14-generic #46-Ubuntu SMP Tue Oct 13 16:47:59
> UTC 2009 i686 GNU/Linux
>
> [ 1237.548049] usb 1-2: new high speed USB device using ehci_hcd and address 3
> [ 1237.696079] hub 1-0:1.0: unable to enumerate USB device on port 2
> [ 1239.357062] usb 1-2: new high speed USB device using ehci_hcd and address 4
> [ 1239.490288] usb 1-2: configuration #1 chosen from 1 choice
> [ 1239.586860] Initializing USB Mass Storage driver...
> [ 1239.588588] scsi6 : SCSI emulation for USB Mass Storage devices
> [ 1239.588863] usb-storage: device found at 4
> [ 1239.588872] usb-storage: waiting for device to settle before scanning
> [ 1239.588898] usbcore: registered new interface driver usb-storage
> [ 1239.588908] USB Mass Storage support registered.
> [ 1244.585060] usb-storage: device scan complete
> [ 1251.245213] gvfsd-metadata[14843]: segfault at 8 ip 0804d2ea sp bff6edf0 error 4 in gvfsd-metadata[8048000+c000]
> [ 1266.113051] usb 1-2: reset high speed USB device using ehci_hcd and address 4
> [ 1266.436046] usb 1-2: reset high speed USB device using ehci_hcd and address 4
> [ 1272.769054] usb 1-2: reset high speed USB device using ehci_hcd and address 4
> [ 1273.105067] usb 1-2: reset high speed USB device using ehci_hcd and address 4
> [ 1273.445079] usb 1-2: reset high speed USB device using ehci_hcd and address 4
> [ 1273.644447] scsi 6:0:0:0: Device offlined - not ready after error recovery"
>
>

[Hated On Mostly (mostly-hated-on)]

Somebody posted what they think is the root of the problem. Maybe others can test it out and give feedback. Very interesting post. CFQ (Completely Fair Queuing) might be the culprit. Links in the post are at the bottom.

http://ubuntuforums.org/showpost.php?p=8124807&postcount=144

I finally found the source of the problem, at least as far as my setup goes. Here's how I did it:

I got frustrated with the Ubuntu/Mint slow transfer rates and decided to check out Fedora. I installed it and ran it for a week or so. Fedora has excellent file transfer speeds, both to and from USB devices and SATA partitions. I copied the kernel config from my Fedora install.

I loaded Mint back into my system and compared the kernel config there with the one I pulled from Fedora. After compileing a half dozen kernels, Kernel I/O Scheduling turned out to be the answer.

By default, since I don't know when, Ubuntu started using CFQ (Completely Fair Queuing) for it's Kernel I/O Scheduling default, but there are a few other options available. Anticipatory and Deadline are the two that seem to work best.

I recompiled a new kernel with the Anticipatory I/O Scheduling and, lo and behold, I had my old 30MB/s USB transfer speeds back, and SATA performance was improves two or three times. (Though it's still not as fast a I think an intra-partition transfer should be on a single SATA hard drive, 10 or 12 megs a second is a lot better than two or three.) There's a noticeable drop in system performance while transfers are taking place, but, at least for me, it wasn't half as bad as it was with CFQ enabled.

Take all that with a grain of salt, though, because I've found forum posts from as far back as 2006 that show people enabling CFQ for the exact same reasons we'll want to disable it here.

Due to some unrelated experiments I was running with Xorg and the catastrophic fail that is the current Intel Video driver setup, I borked my install beyond repair and had to re-do it. Further research into the solution showed me that you can select a default I/O Scheduler at boot up by passing an option on to the kernel.

I found that by appending the string elevator=as to the end of the kernel parameters in /boot/grub/menu.lst, you can enable anticipatory I/O scheduling. The strings elevator=deadline and elevator=noop can be used as well, though I'm not so sure about their effects.

-------------
title Linux Mint 7 Gloria, kernel 2.6.28-15-generic
root (hd0,7)
 kernel /vmlinuz-2.6.28-15-generic root=/dev/sda6 ro quiet splash elevator=as
initrd /initrd.img-2.6.28-15-generic
quiet
-------------

It is also possible to change the I/O scheduler for certain devices without making it a system default, as can be found in these two blog posts.

I'd be interested in seeing if any of you get similar results by trying these solutions.

http://ubuntuforums.org/showthread.php?t=119546
http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/
http://planet.admon.org/howto/how-to-change-default-io-scheduler/

[Hated On Mostly (mostly-hated-on)]

If people could post whether or not CFQ is enabled and whether they still have the slow usb problem that would be great info:

-------------
http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/

Task: View Current Disk scheduler

Assuming that your disk name /dev/sda, type in a terminal:

cat /sys/block/sda/queue/scheduler

--------

Copy and paste the output of the above command.

My system shows:

noop anticipatory [deadline] cfq

Which means my system (9.10 Karmic Koala beta with no updates) is using deadline by default and I am currently not experiencing the problem. I was experiencing the slow USB transfer speeds in 8.04 Hardy Heron and 8.10 Intrepid Ibex.

[Stefano_PG (slot)]

I tested a transfer from sda (ide) to sdb (Usb) of an iso (700mb).
The worst for me is the deadline, wich is about 0.5MB/s slower than cfq.
Anticipatory is about 0.7MB/s faster.
At the end I stay with cfq.

Il 19/10/2009 08:40, Hated On Mostly ha scritto:
> If people could post whether or not CFQ is enabled and whether they
> still have the slow usb problem that would be great info:
>
> -------------
> http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/
>
> Task: View Current Disk scheduler
>
> Assuming that your disk name /dev/sda, type in a terminal:
>
> cat /sys/block/sda/queue/scheduler
>
> --------
>
> Copy and paste the output of the above command.
>
> My system shows:
>
> noop anticipatory [deadline] cfq
>
> Which means my system (9.10 Karmic Koala beta with no updates) is using
> deadline by default and I am currently not experiencing the problem. I
> was experiencing the slow USB transfer speeds in 8.04 Hardy Heron and
> 8.10 Intrepid Ibex.
>
>

[lvm (lvm-royal)]

This problem is indeed alcor-specific, I changed internal card reader from the one based on alcor chipset to realtek and the problem is gone with no other software or hardware changes.

[lisajo (ringwa)]

I don't eally think this is only alcor-specific; please refer to:
http://ubuntuforums.org/showthread.php?p=8415658

Some details on what I tried; regardless, I'm still seeing
“usb 1-5: reset high speed USB device using ehci_hcd and address 3”

Same results with the following Kernels:
Linux ubuntu 2.6.32-5-generic (Lucid daily build 2009-11-30)
Linux ubuntu 2.6.31-50-generic (current one in Karmic)

Also same results trying different schedulers following the post from Hated on Mostly (noop, as and cfq on boot time with Kernel parameter and at runtime as described above).

The hardware involved:
2 external hdds, 3 USB – flash – disks; only difference is that the time to reset in dmesg varies.

The onboard – controller on my MB having all this trouble is:
USB Controller [0c03]: ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]

I do have no other hardware on USB – Bus; not even keyboard and mouse.

How I can get to work with USB:
Disabling USB2.0 – support in BIOS, or using the USB – ports on a USB – PCI – controller I added (because of this bug) with NEC – controller:
USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04)

I think USB2.0 – support should be absolutely reliable on modern computers with a current OS.
Please, review this bug.
I'm not a programming professional, but I'll try providing whatever information can help sorting this out.

Regards, lisajo

[Peter B P (peterbp)]

I've taken a new system into use today and can confirm that the bug is NOT unique to alcor USB chips.

The system log gets spammed with this on trying to read from USB 2.0 mass storage devices:

Dec 18 22:13:56 winter9 kernel: [ 2169.570023] usb 1-3: reset high speed USB device using ehci_hcd and address 2

I am also having severe problems with drive disconnects for 2,5" bus-powered USB units on the same system. (However the drives in question work flawlessly on an older Lenovo Portable system).

The Device Manager shows this to be the USB root hub:

82801JI (ICH10 Family) USB2 EHCI Controller #2
Intel Corporation (ASUSTeK Computer Inc.)
PCI (Peripheral Component Interconnect)

It is a USB controller on an ASUS motherboard; P5QL - EPU (Intel P-43 Chipset).

Hope this helps - this bug is unnerving.

[filip (bandit-s-fw)]

I think i also have this problem on my ext hdd (freecom XXX) when i try to run karmic from it. Tried the daily build (301209) of lucid but the same happens. The strange thing is that it works without a problem with karmic on my usb-stick (cruzer) on the same laptop.
lspci |grep USB
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)

[markofealing (mark-ferns16)]

I've also got this problem with a Freecom 160Gb USB drive Model (SSJABA), known as the Freecom Mobile Drive XXS, it is USB2.

If it is correctly detected by Karmic (also an issue with earlier versions of Ubuntu), it is very slow in reading and writing files (USB 1.1 Speed rather than USB2) when compared to a 80Gb Buffalo MiniStation USB disk I also have.

I've experienced problems on some NEC, VIA (all), and Alcor USB2 controller chipsets, although with Intel I've not had a problem but this is probably because my only Intel USB controller is USB1.1!

Dropping back to USB1.1 drivers fixes the problem but is unworkable with high capacity devices.

[filip (bandit-s-fw)]

markofealing: i misspelled my ext hdd it is also a Freecom Mobile Drive XXS like yours.

[filip (bandit-s-fw)]

I've installed jaunty on my Freecom Mobile Drive XXS to test. There it works everytime without problems but i see that my speeds are very low so i conclude that i must be using uhci. I hope that the dev's will look at this bug as with karmic and lucid the ehci is build in, so it is not possible to simply unload the module. Or am i wrong?

[filip (bandit-s-fw)]

i tried to update my lucid system that i run from my usb hdd (Freecom Mobile Drive XXS) and when updating the package acpi-support it tries to disable acpi powermanagement. that immediately triggers the well known errors: usb 1-4: device descriptor read/64, error .... for a couple of times and the system goes in read only mode and freezes. Maybe this can help solving the problem?

[Pi (pi3832)]

So, if I run:

dmesg | grep ehci*

I get:

[ 0.892115] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.892479] ehci_hcd 0000:00:02.1: PCI INT B -> Link[LUB2] -> GSI 22 (level, low) -> IRQ 22
[ 0.892492] ehci_hcd 0000:00:02.1: setting latency timer to 64
[ 0.892496] ehci_hcd 0000:00:02.1: EHCI Host Controller
[ 0.892547] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
[ 0.892571] ehci_hcd 0000:00:02.1: debug port 1
[ 0.892575] ehci_hcd 0000:00:02.1: cache line size of 64 is not supported
[ 0.892593] ehci_hcd 0000:00:02.1: irq 22, io mem 0xfeafec00
[ 0.904018] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00
[ 0.904459] ehci_hcd 0000:00:04.1: PCI INT B -> Link[UB12] -> GSI 21 (level, low) -> IRQ 21
[ 0.904467] ehci_hcd 0000:00:04.1: setting latency timer to 64
[ 0.904469] ehci_hcd 0000:00:04.1: EHCI Host Controller
[ 0.904503] ehci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 2
[ 0.904524] ehci_hcd 0000:00:04.1: debug port 1
[ 0.904528] ehci_hcd 0000:00:04.1: cache line size of 64 is not supported
[ 0.904544] ehci_hcd 0000:00:04.1: irq 21, io mem 0xfeafe800
[ 0.916016] ehci_hcd 0000:00:04.1: USB 2.0 started, EHCI 1.00
[ 1.340016] usb 2-3: new high speed USB device using ehci_hcd and address 3
[ 4478.536017] usb 1-3: new high speed USB device using ehci_hcd and address 2
[ 6973.480021] usb 2-3: new high speed USB device using ehci_hcd and address 4
[ 6975.872018] usb 2-3: new high speed USB device using ehci_hcd and address 5
[10677.680020] usb 2-3: new high speed USB device using ehci_hcd and address 7
[12922.100581] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[12958.113018] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[12991.113026] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[13030.113026] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[...]
[16805.101018] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[16840.101019] usb 2-3: reset high speed USB device using ehci_hcd and address 7
[16872.101024] usb 2-3: reset high speed USB device using ehci_hcd and address 7

But if I run:

modprobe -r ehci_hcd

I get:

FATAL: Module ehci_hcd not found.

Is my kernel (2.6.31-17) haunted by the ghost of this THREE YEAR OLD bug?

Also, changing 'scheduler' doesn't help. Changing 'max_sectors' doesn't help.

[Andy Rabagliati (andyr)]

@Pi - without more information, we can only cluck sympathetically.

Please attach the results of lspci -vvnn and lsusb - and tell us the result of trying the workarounds described above.

Newer kernels have unmodularised ehci_hcd so it cannot be removed.

You don't really want to remove it because USB transfers will slow to a crawl.

[Lukáš Chmela (lukaschmela)]

Andy Rabagliati píše v So 23. 01. 2010 v 11:08 +0000:
> @Pi - without more information, we can only cluck sympathetically.
>
> Please attach the results of lspci -vvnn and lsusb - and tell us the
> result of trying the workarounds described above.
>
> Newer kernels have unmodularised ehci_hcd so it cannot be removed.
>
> You don't really want to remove it because USB transfers will slow to a
> crawl.
>

Hi,
I am still experiencing this very ugly bug, although it affects only
"selected" devices that I have.
I think, it is related only to USB mass storage devices, as my camera
connected through USB and communicating through gphoto2 protocol works
fine when transferring data.

I have problem only with my USB memory card reader and my mobile phone
(when connected through usb mass storage mode) - those are the only USB
mass storage devices that I have.
These devices keeps resetting immediately after a specific amount data
has been transferred. For instance, my USB card reader is always reset
after every ~5 photo previews loaded in Nautilus and my mobile phone is
even not able to connect. It keeps turning its display off and on and in
system protocol still roll the same messages "usb 1-6: reset high speed
USB device using ehci_hcd and address 5" consequently.

I attach output of lspci -vvnn and lsusb on your request.

--
Lukáš Chmela <email address hidden>
IRC: <email address hidden>, ICQ: 202077459
514D 3C69 8498 E400 0ACE 90F2 00E3 CACA A5BA ECC7

[filip (bandit-s-fw)]

For my freecom XXS drive, i think also like mentioned in the devel-list that this is a very low level bug. If i boot from my disk it resets two times until i get to the desktop. But most of the times i doesn't get there. If i look in the logs the resets are not always on the same time. The resets already accured after disk recovery before the udev rules kick in.
If i connect the drive while running a full up to date lucid (on my usb-stick cruzer here no problem) i get this:

[ 626.470346] usb 1-5: new high speed USB device using ehci_hcd and address 5
Jan 27 19:17:11 lucidext kernel: [ 626.621195] usb 1-5: configuration #1 chosen from 1 choice
Jan 27 19:17:11 lucidext kernel: [ 626.622687] scsi7 : SCSI emulation for USB Mass Storage devices
Jan 27 19:17:16 lucidext kernel: [ 631.620682] scsi 7:0:0:0: Direct-Access Freecom Mobile Drive XXS PQ: 0 ANSI: 2 CCS
Jan 27 19:17:16 lucidext kernel: [ 631.621505] sd 7:0:0:0: Attached scsi generic sg3 type 0
Jan 27 19:17:16 lucidext kernel: [ 631.624982] sd 7:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)
Jan 27 19:17:16 lucidext kernel: [ 631.625774] sd 7:0:0:0: [sdc] Write Protect is off
Jan 27 19:17:16 lucidext kernel: [ 631.627691] sdc: sdc1 sdc2 sdc3 < sdc5 sdc6 > sdc4
Jan 27 19:17:16 lucidext kernel: [ 631.696161] sd 7:0:0:0: [sdc] Attached SCSI disk
Jan 27 19:17:23 lucidext kernel: [ 639.130061] usb 1-5: reset high speed USB device using ehci_hcd and address 5
Jan 27 19:17:31 lucidext kernel: [ 647.130060] usb 1-5: reset high speed USB device using ehci_hcd and address 5
Jan 27 19:18:02 lucidext kernel: [ 678.100318] usb 1-5: USB disconnect, address 5
Jan 27 19:18:02 lucidext kernel: [ 678.100343] sd 7:0:0:0: Device offlined - not ready after error recovery
Jan 27 19:18:02 lucidext kernel: [ 678.100361] sd 7:0:0:0: [sdc] Unhandled error code
Jan 27 19:18:02 lucidext kernel: [ 678.100365] sd 7:0:0:0: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
Jan 27 19:18:02 lucidext kernel: [ 678.100372] sd 7:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 00 00 00 20 00
Jan 27 19:18:02 lucidext kernel: [ 678.100397] __ratelimit: 9 callbacks suppressed
Jan 27 19:18:02 lucidext kernel: [ 678.101560] sd 7:0:0:0: [sdc] Unhandled error code
Jan 27 19:18:02 lucidext kernel: [ 678.101564] sd 7:0:0:0: [sdc] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jan 27 19:18:02 lucidext kernel: [ 678.101571] sd 7:0:0:0: [sdc] CDB: Read(10): 28 00 0d f8 ba 3f 00 00 02 00
Jan 27 19:18:03 lucidext kernel: [ 678.400059] usb 1-5: new high speed USB device using ehci_hcd and address 6
Jan 27 19:18:03 lucidext kernel: [ 678.551204] usb 1-5: configuration #1 chosen from 1 choice
Jan 27 19:18:03 lucidext kernel: [ 678.553600] scsi8 : SCSI emulation for USB Mass Storage devices
Jan 27 19:18:08 lucidext kernel: [ 683.592443] scsi 8:0:0:0: Direct-Access Freecom Mobile Drive XXS PQ: 0 ANSI: 2 CCS
Jan 27 19:18:08 lucidext kernel: [ 683.593290] sd 8:0:0:0: Attached scsi generic sg3 type 0
Jan 27 19:18:08 lucidext kernel: [ 683.664169] sd 8:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB)
Jan 27 19:18:08 lucidext kernel: [ 683.664905] sd 8:0:0:0: [sdc] ...

[filip (bandit-s-fw)]

I don't think it is a problem with the powersupply of the usb as my other externel hdd isn't usb-powered and i also get the same error messages.

[AlfonSkunk (alfonskunk)]

Since the last generic kernel in Karmic-Updates (2.6.31-20-57) everythings seems to go fine...

On changelog are some USB-related changes, but i can't determine which is the answer.

Debian-testing, kernel 2.6.32, has the same problem.

chipset USB: AMD SB600

some ports with USB 1.1 devices connected had ohci loaded, and the port with WDPassport HDD loads ehci without any error. Large transfers ok, without resets

I hadn't any "trick" of above, I made a new instalation.

Do you need any info?

[draco (draco31-fr)]

Hi,

On my case, almost all bugs related to usb are gone since kernel 2.6.32.9
Previously, with kernel 2.6.32.2, I still have major issues (no
detection / frequent usb reset / disconnection during transfer ...)
I don't try kernels between 2.632.2 and 2.6.32.9
Hope the fixes will be avaible in Lucid kernel or almost in proposed.

draco

AlfonSkunk a écrit :
> Since the last generic kernel in Karmic-Updates (2.6.31-20-57)
> everythings seems to go fine...
>
> On changelog are some USB-related changes, but i can't determine which
> is the answer.
>
> Debian-testing, kernel 2.6.32, has the same problem.
>
> chipset USB: AMD SB600
>
> some ports with USB 1.1 devices connected had ohci loaded, and the port
> with WDPassport HDD loads ehci without any error. Large transfers ok,
> without resets
>
> I hadn't any "trick" of above, I made a new instalation.
>
> Do you need any info?
>
>

[battmanux (battmanu)]

Hi AlfonSkunk,

I feel like having the same hardware than you, but the issu is not solved for me. That said, it seems to behave better than previous kernels. I will try to load 2.6.32.9+

Thanks for the update.

uname:
2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux
lspic:
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
dmesg:
[ 108.209937] scsi 6:0:0:0: Direct-Access WD 2500BEV External 1.04 PQ: 0 ANSI: 4
[ 108.210653] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 108.215206] sd 6:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[ 108.216893] sd 6:0:0:0: [sdb] Write Protect is off
[ 108.216901] sd 6:0:0:0: [sdb] Mode Sense: 21 00 00 00
[ 108.216907] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 108.222198] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 108.222212] sdb:
[ 138.888961] usb 1-2.4: reset high speed USB device using ehci_hcd and address 7
[ 139.048916] sdb1
[ 169.877395] usb 1-2.4: reset high speed USB device using ehci_hcd and address 7
[ 169.971242] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 169.971257] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 200.876870] usb 1-2.4: reset high speed USB device using ehci_hcd and address 7
[ 231.876678] usb 1-2.4: reset high speed USB device using ehci_hcd and address 7
[ 262.889156] usb 1-2.4: reset high speed USB device using ehci_hcd and address 7
...

[Ka-Hing Cheung (kahing)]

00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
Linux struggle64 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 x86_64 GNU/Linux

With Lucid kernel, the situation improved compared to when I last tried in karmic. I can now copy bigger files without failing, but it's still failing in the couple hundred MBs range:

Mar 14 17:56:12 struggle64 kernel: [166687.122634] usb 2-5: reset high speed USB
 device using ehci_hcd and address 12
Mar 14 17:56:42 struggle64 kernel: [166717.710350] usb 2-5: reset high speed USB
 device using ehci_hcd and address 12
Mar 14 17:57:13 struggle64 kernel: [166748.293341] usb 2-5: reset high speed USB
 device using ehci_hcd and address 12
Mar 14 17:57:24 struggle64 kernel: [166758.831391] usb 2-5: reset high speed USB
 device using ehci_hcd and address 12
Mar 14 17:57:34 struggle64 kernel: [166769.252614] usb 2-5: USB disconnect, address 12
Mar 14 17:57:34 struggle64 kernel: [166769.252645] sd 15:0:0:0: Device offlined - not ready after error recovery
Mar 14 17:57:34 struggle64 kernel: [166769.252677] sd 15:0:0:0: [sdc] Unhandled error code
Mar 14 17:57:34 struggle64 kernel: [166769.252681] sd 15:0:0:0: [sdc] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Mar 14 17:57:34 struggle64 kernel: [166769.252690] sd 15:0:0:0: [sdc] CDB: Write(10): 2a 00 00 00 01 e0 00 00 f0 00
Mar 14 17:57:34 struggle64 kernel: [166769.252725] lost page write due to I/O error on sdc

[thomas f (wastedfluid-gmail)]

I have the same problem as many users.

Computer: Acer Aspire 5700

Randomly, my usb 2.0 drive disconnects and gives me a:

I have to remount - when I do, it's only at usb 1.1 speed until I restart... a lot of the time, I just have to restart - only to wait one more day for this to happen again.

Other interesting notes: All devices connected via USB(I have a hub that has a mouse, keyboard, and cell phone charger attached) do not work after this said event. The harddrive has its own power hookup. However, they do have power as my mouse's laser is on.

This JUST started happening when I upgraded to Ubuntu 9.10.

van@lywex:~$ uname -a
Linux lywex 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux
van@lywex:~$ lsusb
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. M-UV69a/HP M-UV96 Optical Wheel Mouse
Bus 001 Device 005: ID 046d:c312 Logitech, Inc. DeLuxe 250 Keyboard
Bus 001 Device 003: ID 0402:5602 ALi Corp. Video Camera Controller
Bus 001 Device 002: ID 050d:0304 Belkin Components
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 1058:1100 Western Digital Technologies, Inc.
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
van@lywex:~$

Mar 17 18:57:03 lywex kernel: [77088.124106] usb 1-7: reset high speed USB device using ehci_hcd and address 4
Mar 17 18:57:18 lywex kernel: [77103.299319] usb 1-7: device descriptor read/64, error -110
Mar 17 18:57:34 lywex kernel: [77118.548148] usb 1-7: device descriptor read/64, error -110
Mar 17 18:57:34 lywex kernel: [77118.764072] usb 1-7: reset high speed USB device using ehci_hcd and address 4
Mar 17 18:57:49 lywex kernel: [77133.912079] usb 1-7: device descriptor read/64, error -110
Mar 17 18:58:04 lywex kernel: [77149.164101] usb 1-7: device descriptor read/64, error -110
Mar 17 18:58:04 lywex kernel: [77149.380087] usb 1-7: reset high speed USB device using ehci_hcd and address 4
Mar 17 18:58:15 lywex kernel: [77159.812079] usb 1-7: device not accepting address 4, error -110
Mar 17 18:58:15 lywex kernel: [77159.924129] usb 1-7: reset high speed USB device using ehci_hcd and address 4
Mar 17 18:58:25 lywex kernel: [77170.356082] usb 1-7: device not accepting address 4, error -110
Mar 17 18:58:25 lywex kernel: [77170.356183] usb 1-7: USB disconnect, address 4
Mar 17 18:58:25 lywex kernel: [77170.356194] sd 2:0:0:0: Device offlined - not ready after error recovery
Mar 17 18:58:25 lywex kernel: [77170.356222] sd 2:0:0:0: [sdb] Unhandled error code
Mar 17 18:58:25 lywex kernel:...

[Hunk (enrique-garciasimon)]

External USB drive working ok with Karmic (and with other windows computers and with a DVB recorder), but it does not work with lucid in the same computer.
I could give more information: it does not work never in lucid (2.6.32), but always in karmic (2.6.31)

Karmic (boot from DVD, now I have just lucid installed)

Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

[ 2474.890140] usb 2-1: new high speed USB device using ehci_hcd and address 5
[ 2475.042459] usb 2-1: configuration #1 chosen from 1 choice
[ 2475.049496] scsi8 : SCSI emulation for USB Mass Storage devices
[ 2475.049715] usb-storage: device found at 5
[ 2475.049720] usb-storage: waiting for device to settle before scanning
[ 2480.040382] usb-storage: device scan complete
[ 2480.041025] scsi 8:0:0:0: Direct-Access SAMSUNG HM500JI PQ: 0 ANSI: 2 CCS
[ 2480.041908] sd 8:0:0:0: Attached scsi generic sg3 type 0
[ 2480.055180] sd 8:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[ 2480.055914] sd 8:0:0:0: [sdc] Write Protect is off
[ 2480.055918] sd 8:0:0:0: [sdc] Mode Sense: 34 00 00 00
[ 2480.055922] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 2480.057412] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 2480.057418] sdc: sdc1
[ 2480.096328] sd 8:0:0:0: [sdc] Assuming drive cache: write through
[ 2480.096339] sd 8:0:0:0: [sdc] Attached SCSI disk

Lucid (same disk, same usb connector, same cable ...)It does not work, I am wrinting from karmic, looking in /var/log/messages I see that. I think that dmesg shows other message about I/O error block 0, 1, ... to 7

Mar 18 21:25:47 enrique-laptop kernel: [ 0.000000] Linux version 2.6.32-16-generic (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-3ubuntu1) ) #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 (Ubuntu 2.6.32-16.25-generic)

Mar 18 20:30:46 enrique-laptop kernel: [ 491.690142] usb 2-2: new high speed USB device using ehci_hcd and address 4
Mar 18 20:30:46 enrique-laptop kernel: [ 491.842103] usb 2-2: configuration #1 chosen from 1 choice
Mar 18 20:30:46 enrique-laptop kernel: [ 491.851266] scsi7 : SCSI emulation for USB Mass Storage devices
Mar 18 20:30:51 enrique-laptop kernel: [ 496.851113] scsi 7:0:0:0: Direct-Access SAMSUNG HM500JI PQ: 0 ANSI: 2 CCS
Mar 18 20:30:51 enrique-laptop kernel: [ 496.854597] sd 7:0:0:0: Attached scsi generic sg2 type 0
Mar 18 20:30:51 enrique-laptop kernel: [ 496.855288] sd 7:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Mar 18 20:30:51 enrique-laptop kernel: [ 496.856029] sd 7:0:0:0: [sdb] Write Protect is off
Mar 18 20:30:51 enrique-laptop kernel: [ 496.857537] sdb: sdb1
Mar 18 20:30:51 enrique-laptop kernel: [ 496.863524] sd 7:0:0:0: [sdb] Attached SCSI disk
Mar 18 20:30:59 enrique-laptop kernel: [ 504.160133] usb 2-2: reset high speed USB device using ehci_hcd and address 4
Mar 18 20:31:08 enrique-laptop kernel: [ 513.160121] usb 2-2: reset high speed USB device using ehci_hcd and address 4
Mar 18 20:31:09 enrique-laptop kernel: [ 514.648447] sd 7:0:0:0: [sdb] Unhandled sense code
Mar 18 20:31:09 enrique-laptop kernel: [ 514.648457] sd 7:0:0:0: [sdb] ...

[Hunk (enrique-garciasimon)]

Include the output of dmesg on lucid.
At least in my case It is not a chipset bug: it ALWAYS works in karmic, it NEVER works in lucid (same disk, same computer, same cable)
I am really interested in a solution in lucid: please ask for more info I could provide

2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 x86_64 GNU/Linux

[ 5290.361460] usb-storage: waiting for device to settle before scanning
[ 5295.360404] usb-storage: device scan complete
[ 5295.361003] scsi 6:0:0:0: Direct-Access SAMSUNG HM500JI PQ: 0 ANSI: 2 CCS
[ 5295.364829] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 5295.373050] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[ 5295.373784] sd 6:0:0:0: [sdb] Write Protect is off
[ 5295.373791] sd 6:0:0:0: [sdb] Mode Sense: 34 00 00 00
[ 5295.373797] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 5295.375914] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 5295.375923] sdb: sdb1
[ 5295.399788] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 5295.399798] sd 6:0:0:0: [sdb] Attached SCSI disk
[ 5303.160301] usb 2-1: reset high speed USB device using ehci_hcd and address 3
[ 5312.160077] usb 2-1: reset high speed USB device using ehci_hcd and address 3
[ 5313.629847] sd 6:0:0:0: [sdb] Unhandled sense code
[ 5313.629857] sd 6:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 5313.629866] sd 6:0:0:0: [sdb] Sense Key : Medium Error [current]
[ 5313.629875] sd 6:0:0:0: [sdb] Add. Sense: Unrecovered read error
[ 5313.629885] sd 6:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 01 00 00 08 00
[ 5313.629904] end_request: I/O error, dev sdb, sector 1
[ 5313.629914] Buffer I/O error on device sdb1, logical block 0
[ 5313.629925] Buffer I/O error on device sdb1, logical block 1
[ 5313.629931] Buffer I/O error on device sdb1, logical block 2
[ 5313.629936] Buffer I/O error on device sdb1, logical block 3
[ 5313.629942] Buffer I/O error on device sdb1, logical block 4
[ 5313.629947] Buffer I/O error on device sdb1, logical block 5
[ 5313.629953] Buffer I/O error on device sdb1, logical block 6
[ 5313.629958] Buffer I/O error on device sdb1, logical block 7

[Jason Harman (apollyon-direct)]

Recently received a similar message after upgrading my 10.04 Beta 1 with some nightly updates. Unfortunately it is my mouse and keyboard that are connected to via Bluetooth and USB which has meant they have been disabled. I have mouse/kb activity until about the time gdm launches at which point they become disabled. Removing the Logitech BT adapter from the USB slot prints this message:

btusb_bulk_complete: hci1 urb ffff88017fa30480 failed to resubmit
btusb_bulk_complete: hci1 urb ffff88017fa30000 failed to resubmit
btusb_send_frame: hci1 urb ffff8801813cb780 submission failed

Attempts to re-insert do not resolve the error and removal of the adapter adds more messages of a similar type to above.

At this time I cannot do anything else in my Lucid 10.04 and have had to file the bug from another platform.

[Sergio Zanchetta (primes2h)]

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

[Sergio Zanchetta (primes2h)]

I've just realized I made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

[Ka-Hing Cheung (kahing)]

This bug (which admittedly, may be multiple bugs affecting different chipsets) is still present in Lucid

[xoristzatziki (simsonbike-bugs)]

As I remember but not exactly either "safely remove" or "umount" does not properly and safely remove the device even in previous ubuntu 64 and 32. I am not sure but I think that right click menu "umount" works but not "safely remove" (after that I had problems with mounting it in windows PC which I used to solve by using a LiveCD, opening the device to see the content, closing and restarting PC with windows)

I think that "safely remove" does not umounts properly the device.

Cannot reproduce the problem since it appears randomly.

this is from last unfortunate time:
I inserted the usb, (fat32), made some heavy copy, move etc.
After copy tried to delete some files but were not deleted ( right click menu "to trash" was dimmed).
I tried "safely remove" or "umount" from right click menu. (Do not remember for sure)
I removed usb after some seconds that ubuntu did nothing -but removed icon from desktop, tried it in some XP pro which found it as non formatted, retried some times in ubuntu. (removing it from one usb slot and inserting it in the other

ilias@fserver2:~$ uname -a
Linux fserver2 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux
from messages.log
...
May 24 19:03:05 fserver2 kernel: [36862.532225] usb 1-2: new high speed USB device using ehci_hcd and address 2
May 24 19:03:06 fserver2 kernel: [36862.684119] usb 1-2: configuration #1 chosen from 1 choice
May 24 19:03:06 fserver2 kernel: [36862.737500] Initializing USB Mass Storage driver...
May 24 19:03:06 fserver2 kernel: [36862.737625] scsi4 : SCSI emulation for USB Mass Storage devices
May 24 19:03:06 fserver2 kernel: [36862.737770] usbcore: registered new interface driver usb-storage
May 24 19:03:06 fserver2 kernel: [36862.737807] USB Mass Storage support registered.
May 24 19:03:11 fserver2 kernel: [36867.733222] scsi 4:0:0:0: Direct-Access A-DATA USB Flash Drive 0.00 PQ: 0 ANSI: 2
May 24 19:03:11 fserver2 kernel: [36867.733646] sd 4:0:0:0: Attached scsi generic sg4 type 0
May 24 19:03:11 fserver2 kernel: [36867.734848] sd 4:0:0:0: [sdd] 31588352 512-byte logical blocks: (16.1 GB/15.0 GiB)
May 24 19:03:11 fserver2 kernel: [36867.735468] sd 4:0:0:0: [sdd] Write Protect is off
May 24 19:03:11 fserver2 kernel: [36867.737958] sdd: sdd1
May 24 19:03:11 fserver2 kernel: [36868.065725] sd 4:0:0:0: [sdd] Attached SCSI removable disk
May 24 19:03:11 fserver2 kernel: [36868.490683] usb 1-2: reset high speed USB device using ehci_hcd and address 2
May 24 19:03:14 fserver2 kernel: [36871.379937] usb 1-2: reset high speed USB device using ehci_hcd and address 2
.... hundreds of the same msg
May 24 19:05:20 fserver2 kernel: [36996.847299] usb 1-2: reset high speed USB device using ehci_hcd and address 2
May 24 19:05:41 fserver2 pulseaudio[1558]: ratelimit.c: 364 events suppressed
May 24 19:05:50 fserver2 kernel: [37027.520881] usb 1-2: reset high speed USB device using ehci_hcd and address 2
.... hundreds of the same msg
May 24 19:31:21 fserver2 kernel: [38557.991283] usb 1-2: reset high speed USB device using ehci_hcd and address 2
May 24 19:33:46 fserver2 kernel: [38702.933288] npviewer.bin[7782]: segfault at ff999ea8 ip 00000000ff999ea8 sp 00000000ffe27f...

[Jeremy Foshee (jeremyfoshee)]

Folks,
     This bug, due in very large part to the huge amount of comments it has received, is no longer useful at all from a bug fix standpoint. As such, I am marking this bug Won't Fix.

If you are affected by a bug that has been marked as a duplicate of this one, please unmark the duplicate. This is in keeping with the new Ubuntu Kernel Team policy of treating each bug as a separate issue even if the hardware and the error is exactly the same. The reasoning for this is that fixes for some bugs that appear to be duplicates do not always fix all possible duplicates and we have found that most of the cases were not reported as bugs with all debug information attached.

For those affected by this who have not filed a bug, please do so now including all relevant debugging and logging so that we can begin the process of looking into your issue on its merit.

For those wishing to simply discuss the issue, please see the forum for relevant threads on the subject while keeping in mind that the Ubuntu Kernel Team does not frequent the forum so you should take any advice you are given for what it is, advice only.

Thanks!

~JFo

[Andy Rabagliati (andyr)]

> This bug, due in very large part to the huge amount of comments it has received, is no longer useful at all from a bug fix standpoint. As such, I am marking this bug Won't Fix.

There are plenty of detailed logs in the comments (including my own) that are presented to help fix this long-standing bug.

I think it is a cop-out to say that all the *other* comments invalidate this bug.

I request that the bug be re-opened.

By all means delete all other non-useful comments.

[Jeremy Foshee (jeremyfoshee)]

Andy,
    I regret that you feel this to be some sort of 'cop out', however, I am acting in my official capacity as the Kernel Bug Supervisor. It appears you are relatively unfamiliar with Launchpad as there is no facility for deleting non-useful comments. Even if there were, it would be a misuse of time to read through the 590 comments in this bug to determine what was of use. It is the Kernel Teams policy to close such bugs and have affected reporters open new bugs. This is the reason for my subsequent closing of this bug. I have asked for, and frankly hope for additions to Launchpad in the future that i anticipate will help in situations like this. Those are not yet reality. Your remark that there are plenty of detailed logs attached also illustrates a part of the problem. Were this bug to reach one of my Engineers, it would be impossible to wade through all of the logs to 1) verify the issue and 2) determine a fix.

I also think you may be suffering from a mis-perception of the Ubuntu Kernel Team. This team is focused on providing relevant stable updates from upstream in a versioned distribution of Ubuntu released every six months. That said, the team's focus is not on bug resolution but rather on insuring that the relevant and needed patches to address a majority of hardware are included upon release. Any issue that needs to be addressed in a different manner needs to be brought to the attention of the Linux Kernel maintainers via bugzilla.kernel.org.

I hope you find this useful.

Thanks!

~JFo

[johnnyb0y (ubuntu64)]

I'm STILL affected by this bug, on different media (External HDD powered USB2 drives, and flash drives). This is on Lucid Lynx.

TO summarise, I think the frustrations felt by the user community are valid. Looking at the top of this thread reveals the following rather pertinent information and it certainly gives the impression that nothing is being done about it. To inject a little humour, it makes you sound like Kevin The Teenager ;-) Can't fix, won't fix.

Won't Fix
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Hobbs
Declined for Karmic by Steve Langasek
   Hardy
Won't Fix
   Intrepid
Won't Fix
   Jaunty
Won't Fix
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Hobbs
Declined for Karmic by Steve Langasek
   Hardy
Won't Fix
   Intrepid
   Jaunty
Won't Fix
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Hobbs
Declined for Karmic by Steve Langasek
   Hardy
Won't Fix
   Intrepid
Won't Fix

I look forward to the day when this bug is finally fixed, and thank you guys in advance for the effort.

Regards

John Goodwin.

[Ralph (kesselr1)]

Page 1 (Scheduler not running?):
{'cups_connection_failure': False}
Page 2 (Choose printer):
{'cups_dest': <cups.Dest Lexmark_3600-4600_Series>,
 'cups_instance': None,

Dump of lusb-v:

Bus 002 Device 005: ID 046d:c044 Logitech, Inc. LX3 Optical Mouse
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x046d Logitech, Inc.
  idProduct 0xc044 LX3 Optical Mouse
  bcdDevice 27.20
  iManufacturer 1 Logitech
  iProduct 2 USB-PS/2 Optical Mouse
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 34
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 98mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Device
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 2 Mouse
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.10
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 59
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0005 1x 5 bytes
        bInterval 10
Device Status: 0x0000
  (Bus Powered)

Bus 002 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize0 64
  idVendor 0x05e3 Genesys Logic, Inc.
  idProduct 0x0608 USB-2.0 4-Port HUB
  bcdDevice 77.63
  iManufacturer 0
  iProduct 1 USB2.0 Hub
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 25
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 10...

[Malachi de AElfweald (malachid)]

I'm seeing the same thing in 13.04 w/ Samsung Galaxy Note. It used to work fine, but after upgrading from 12.10->13.04 and from ICS->JB, this device is unusable from Ubuntu. Dual boot to Windows and it works fine.

Linux hydra 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Attached file is log from plugging device in for just a moment. If I leave it connected, I will get a never-ending stream of popups that look like "Unable to open MTP device '[usb:003,021]'" with 021 rotating between all numbers up to 127 and then starting over. I believe that is caused by the constant flow of:

Jun 8 07:11:52 hydra kernel: [ 525.282788] usb 3-4: reset high-speed USB device number 3 using ehci-pci
Jun 8 07:11:52 hydra kernel: [ 525.362789] usb 3-4: USB disconnect, device number 3

[Malachi de AElfweald (malachid)]

This has started happening on my other Ubuntu box now. Turning off 'usb debugging' makes the problem go away - of course that means no longer using ADB.

[Narcis Garcia (narcisgarcia)]

I had this problem with Ubuntu-Gnome 13.04 on a HP Pavilion g6 laptop. Some USB ports didn't work (as if they didn't exist).
My workaround has been to add "nomodeset" parameter to kernel boot parameters.

[Malachi de AElfweald (malachid)]

I just switched from the Samsung Galaxy Note to the Google Edition of HTC One and do not have this problem with the new device. Maybe Samsung specific?

[kes-kes (kes-kes-linux-kernel-bugs)]

I were injured this problem too. When I install clean system 17.0 Linux mint all were OK. During some updates by 'Update manager' on 17.1 the problem were rised.

The hardware has not been changed

This is my post: http://askubuntu.com/questions/666601/system-is-loading-about-10-min-what-is-comming-on with messages on logs.

This problem does not exists when rebooting. It is only when cool start.

[kes-kes (kes-kes-linux-kernel-bugs)]

Linux keshome 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[kes-kes (kes-kes-linux-kernel-bugs)]

updating to 3.16/4.1.3/4.2 has no any effect

Linux keshome 4.2.0-040200-generic #201508301530 SMP Sun Aug 30 19:31:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[stern (stern-linux-kernel-bugs)]

KES777, do you know of a kernel version that worked okay? And can you attach the log messages to this bug report? The Ubuntu question has been removed.

[kes-kes (kes-kes-linux-kernel-bugs)]

Created attachment 189931
log file with problems

The log file where you can see problem:
[ 3222.072011] usb 1-2: new high-speed USB device number 59 using ehci-pci

When this problem occurs
the FF tabs with adobe flash player does not work ,whole FF is halted.
Also can not run VirtualBox guest OS
Also the theme on desktop is changed to some other theme

Cool start has always this problem.
Sometimes when rebooting there is no this problem.

[stern (stern-linux-kernel-bugs)]

It sounds like your computer has lots of problems, not just with USB. Have you checked to see if a BIOS update is available?

[kes-kes (kes-kes-linux-kernel-bugs)]

Booting from [linuxmint-17.1-cinnamon-64bit.iso](https://www.google.com.ua/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCcQFjABahUKEwjb96KftL3IAhVFBywKHZpiC4w&url=http%3A%2F%2Fwww.linuxmint.com%2Fedition.php%3Fid%3D172&usg=AFQjCNGhNbBoPHn7h7j5jLG6Cgrs3xpogA&sig2=EiLtHf60Iuqh6l7cX0WtJw) has no any of those problems.

[stern (stern-linux-kernel-bugs)]

If you know which kernel version works and which one doesn't work, you can use git bisect to find the cause of the problem.

[kes-kes (kes-kes-linux-kernel-bugs)]

I do not know how to use it, how to compile my own kernel, install etc.

[kes-kes (kes-kes-linux-kernel-bugs)]

Created attachment 190741
log files of different OSes caused and not caused by this problem

The OSes:
1. Windows 7
2. Windows XP
3. FreeBSD 9.3
are not affected by "new high-speed USB device number" problem. They works fine.
The FreeBSD 9.3 just report about some error for umass:

Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Retrying command
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted

4. cinnamon mint 15 (3.8.0-19-generic) works fine, but kern.log file is spamed by this messages:

Oct 21 13:54:17 kes-desktop kernel: [ 4260.504011] usb 1-2: new high-speed USB device number 34 using ehci-pci
Oct 21 13:54:17 kes-desktop kernel: [ 4260.572330] hub 1-0:1.0: unable to enumerate USB device on port 2
Oct 21 13:54:17 kes-desktop kernel: [ 4260.788218] hub 1-0:1.0: unable to enumerate USB device on port 2

5. ubuntu 12.04 also is not affected.

These has problems:
1. ubuntu 14.04. It is loading too slow and after loading I can not visit sites that uses adobe_flash plugin. The browser is halted (see print_screen: ubuntu-14.04-ishalted.png).

2. cinnamon-mint-16
3. Fresh installation of 17.1

I also want to check how work mint 14 and 13, but I can not install them due to the installer error

The detailed log messages for those systems see at attachment

It seems some bug is introduced to the new kernels. If someone give me detaided instructions how to use bisect and how to compile/install kernels from source I can complete that.
Thank you.

[stern (stern-linux-kernel-bugs)]

There are lots of tutorials explaining how to use git bisect and how to build/install kernels. Google is your friend.

[maomfamao (maomfamao-linux-kernel-bugs)]

Thanks guys, I’ve been looking for this information for a long time, I'm glad to join your community. https://www.19216811ip.mobi

[clarkembers (clarkembers-linux-kernel-bugs)]

I am from Alberta, Canada. I am really happy to be a member of this forum. thanks.

[davidgutierrez2253 (davidgutierrez2253-linux-kernel-bugs)]

Hello, I'm Marieromig We will help you get into your Router Login or other devices on your network. 192.168.1.250 is a private IP address used for local networks. After that, you face any issues so you can Call us at + 1-844-726-2255 visit : https://my-wifiextnet.net/genie-setup/

[Mywifiextsetupus (mywifiextsetupus-linux-kernel-bugs)]

log files of different OSes caused and not caused by this problem

The OSes:
1. Windows 7
2. Windows XP
3. FreeBSD 9.3
are not affected by "new high-speed USB device number" problem. They works fine.
The FreeBSD 9.3 just report about some error for umass:

Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Retrying command
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted

4. cinnamon mint 15 (3.8.0-19-generic) works fine, but kern.log file is spamed by this messages:

Oct 21 13:54:17 kes-desktop kernel: [ 4260.504011] usb 1-2: new high-speed USB device number 34 using ehci-pci
Oct 21 13:54:17 kes-desktop kernel: [ 4260.572330] hub 1-0:1.0: unable to enumerate USB device on port 2
Oct 21 13:54:17 kes-desktop kernel: [ 4260.788218] hub 1-0:1.0: unable to enumerate USB device on port 2

5. ubuntu 12.04 also is not affected.

These has problems:
1. ubuntu 14.04. It is loading too slow and after loading I can not visit sites that uses adobe_flash plugin. The browser is halted (see print_screen: ubuntu-14.04-ishalted.png).

2. cinnamon-mint-16
3. Fresh installation of 17.1

I also want to check how work mint 14 and 13, but I can not install them due to the installer error

The detailed log messages for those systems see at attachment

It seems some bug is introduced to the new kernels. If someone give me detaided instructions how to use bisect and how to compile/install kernels from source I can complete that.
Thank you.