ehci_hcd module causes I/O errors in USB 2.0 devices

Bug #88746 reported by Al Buntu on 2007-02-28
820
This bug affects 117 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Medium
linux (Fedora)
Invalid
Medium
linux (Ubuntu)
High
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Kowalik
Declined for Karmic by Steve Langasek
Hardy
High
Unassigned
Intrepid
High
Unassigned
Jaunty
High
Unassigned
linux-source-2.6.20 (Ubuntu)
High
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Kowalik
Declined for Karmic by Steve Langasek
Hardy
High
Unassigned
Intrepid
High
Unassigned
Jaunty
High
Unassigned
linux-source-2.6.22 (Baltix)
Undecided
Unassigned
linux-source-2.6.22 (Ubuntu)
High
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Declined for Intrepid by Sarah Kowalik
Declined for Karmic by Steve Langasek
Hardy
High
Unassigned
Intrepid
Undecided
Unassigned
Jaunty
High
Unassigned

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 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) wrote :

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.

description: updated
Al Buntu (biedermann2) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Al Buntu (biedermann2) wrote :
Al Buntu (biedermann2) wrote :
Al Buntu (biedermann2) wrote :
pirast (pirast) wrote :

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)

pirast (pirast) wrote :

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

Though, I will also attach my outputs.

pirast (pirast) wrote :
pirast (pirast) wrote :
pirast (pirast) wrote :
pirast (pirast) wrote :

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

Al Buntu, which mainboard do you have?

description: updated

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) wrote :

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

Changed in linux-source-2.6.20:
assignee: nobody → kyle
status: Confirmed → Needs Info
pirast (pirast) wrote :
pirast (pirast) wrote :
Changed in linux-source-2.6.20:
status: Needs Info → Confirmed

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
>
>

fixed in 2.6.20-10

Changed in linux-source-2.6.20:
status: Confirmed → Fix Released
pirast (pirast) wrote :

reappeard in 2.6.20-12-generic

Changed in linux-source-2.6.20:
assignee: kyle → ubuntu-kernel-team
status: Fix Released → Confirmed
pirast (pirast) on 2007-03-24
Changed in linux-source-2.6.20:
importance: Undecided → High
Jared Sutton (jpsutton) wrote :

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) wrote :

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.

pirast (pirast) wrote :

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

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
>

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...

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.
>

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

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.
>

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

John Zero (johnzero) wrote :
stephg (stephg) wrote :

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) wrote :

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.

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

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?)

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?

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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.

description: updated

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.

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.

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

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

Here is the lsusb with the devices now working.

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

Paulo Pereira (pjpereira) wrote :

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.

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

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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Miguel Diago (mdm) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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 (c-schurig) wrote :

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) wrote :

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) wrote :

@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)

Alwin Garside (yogarine) on 2007-05-28
description: updated
brim4brim (maherb) wrote :

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) wrote :

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).

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

The usbfs trick neither worked for me. :-(

biffster (biffster) wrote :

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) wrote :

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) wrote :

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.

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 ;)

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

Robert North (russetrob) wrote :

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

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.

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) wrote :

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.

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) wrote :

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

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.

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) wrote :

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

Andrew Straw (astraw) wrote :

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) wrote :

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

Robert North (russetrob) wrote :

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) wrote :

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

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.

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) wrote :

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) wrote :

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) wrote :

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

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.

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!

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.

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.

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"

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

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

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) wrote :

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

midnightflash (midnightflash) wrote :

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) wrote :

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

Henrik Nilsen Omma (henrik) wrote :

Reproduced on Gutsy, moving task properties.

Changed in linux-source-2.6.22:
status: New → Invalid
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
status: New → Confirmed
Henrik Nilsen Omma (henrik) wrote :

Too late for Feisty.

Changed in linux-source-2.6.20:
status: Confirmed → Won't Fix

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

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.

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

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) wrote :

and here's the lspci-vvnn.log :

Barteq (barteqpl) wrote :
Download full text (3.8 KiB)

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 ...

Read more...

Brian Murray (brian-murray) wrote :

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.

Changed in linux-source-2.6.22:
status: Confirmed → Triaged
midnightflash (midnightflash) wrote :

~$ 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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

808y (808y) wrote :

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) wrote :
808y (808y) wrote :
808y (808y) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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.

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)

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.

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?

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) on 2007-10-30
description: updated
Alwin Garside (yogarine) wrote :

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) wrote :

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

albuntu (mail-trinnes) wrote :

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.

albuntu (mail-trinnes) wrote :

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.

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.

pirast (pirast) on 2007-11-02
Changed in linux-source-2.6.22:
status: Triaged → Fix Released
808y (808y) wrote :

? 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) wrote :

> 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.

Yes, I find that particularly great as well.

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

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) wrote :

@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) wrote :

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) wrote :

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

Changed in linux-source-2.6.22:
status: Fix Released → Confirmed
albuntu (mail-trinnes) wrote :

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.

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) wrote :

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

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) wrote :

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?

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.)

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.

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) wrote :

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) wrote :

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

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
status: New → Triaged
Robert North (russetrob) 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.

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) wrote :

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) wrote :

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) wrote :

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

Robert North (russetrob) wrote :

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

Robert North (russetrob) wrote :

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

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) 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) wrote :

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) wrote :

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!

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

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) wrote :

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) wrote :

My dmesg.log file...

iMaNeX (imanex) wrote :

My lspci.log file...

iMaNeX (imanex) wrote :

My lsusb.log file...

Pär Lidén (par-liden) wrote :

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.

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) wrote :

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) wrote :

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

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) wrote :

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) wrote :

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.

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) wrote :

Closing the Gutsy task and approving the Hardy target nomination.

Changed in linux-source-2.6.22:
status: Confirmed → Won't Fix

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) wrote :

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) wrote :

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) 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.

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) wrote :

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) wrote :

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) 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."

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

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

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:
status: Triaged → Incomplete
nusigmaforce (doctorcelebro) wrote :

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) wrote :

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) wrote :

@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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) 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)

Markus Kienast (elias1884) 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!!!!

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)
>

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!!!!

Changed in linux:
status: Incomplete → Triaged
nusigmaforce (doctorcelebro) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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

>@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) wrote :

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) wrote :

Still failing in hardy a4.

Robert North (russetrob) wrote :

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) wrote :

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) wrote :

>>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.

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) 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 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.

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) wrote :

>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) 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.

--
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.

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) wrote :

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) wrote :

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) wrote :

>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) wrote :

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

Download full text (4.0 KiB)

@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 ...

Read more...

Download full text (6.0 KiB)

@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...

Read more...

Download full text (8.0 KiB)

@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...

Read more...

rod singleton (rod40cool) wrote :

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

Tim Gardner (timg-tpi) on 2008-02-13
Changed in linux-source-2.6.22:
status: Confirmed → Won't Fix
Changed in linux:
status: Triaged → Won't Fix
status: Triaged → Won't Fix
Robert North (russetrob) wrote :

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) wrote :

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

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) wrote :

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) wrote :

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) 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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.
>

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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).

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) wrote :

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?

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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?

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

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.

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) wrote :

>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) wrote :

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) 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,

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) wrote :

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) wrote :
Download full text (3.7 KiB)

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...

Read more...

pirast (pirast) wrote :

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

Changed in linux:
status: Won't Fix → Confirmed

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.

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

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) wrote :

Why is this not going to be fixed?

Mackenzie Morgan (maco.m) wrote :

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?

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) wrote :

> Why is this not going to be fixed?

It's not a particularly sexy problem...

Matt LaPaglia (mlapaglia) wrote :

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) wrote :

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) wrote :

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) wrote :

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

nusigmaforce (doctorcelebro) wrote :
  • unnamed Edit (1.1 KiB, text/html; charset="iso-8859-1")

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in linux:
status: Unknown → Incomplete
FoolsRun (michael-delaney) wrote :

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) wrote :

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.

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) wrote :

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.

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) wrote :

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...

@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>
>

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) 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...

J.O.

aschuring (aelschuring) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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:

Created attachment 16976
dmesg

Created attachment 16977
kernel output (before and after)

Created attachment 16978
lsusb

after the ehci module get confused

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

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)

Created attachment 16980
my kernel config

Download full text (3.9 KiB)

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...

Read more...

Download full text (3.2 KiB)

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 ...

Read more...

Download full text (3.5 KiB)

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...

Read more...

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)

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

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 ?

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

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
>
>

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 ...

On Fri, 25 Jul 2008, Bal

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

On Sun, 27 Jul 2008, Bal

Created attachment 17009
ehci registers before

Created attachment 17010
ehci registers after

after pendrive attached and the ehci module went wrong

xens (r-aviolat) wrote :

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) wrote :

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.

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.

On Thu, 31 Jul 2008, Bal

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

On Thu, 31 Jul 2008, Bal

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)

On Thu, 31 Jul 2008, Bal

Reply-To: <email address hidden>

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

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!

On Fri, 1 Aug 2008, Bal

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

Download full text (3.3 KiB)

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...

Read more...

LewCPE (lewcpe) wrote :

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) wrote :

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

Changed in linux:
status: Incomplete → Invalid

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) wrote :

Hey!
Invalid? It's BROKEN!!!

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

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

On Tue, 19 Aug 2008, Bal

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
>
>

On Tue, 19 Aug 2008, Bal

(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) wrote :

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) wrote :

+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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

@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.

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>

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) wrote :

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) wrote :
Download full text (5.3 KiB)

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...

Read more...

phaidros (phaidros) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

my lspci -vvnn

alphalupus08 (guthlaf) wrote :

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 :-(

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.

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) wrote :
Download full text (4.0 KiB)

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...

Read more...

Denilson Sá (denilsonsa) wrote :

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.

The other people found that removing their hubs fixed the problem. Does this work for you?

AlfonSkunk (alfonskunk) wrote :

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) wrote :

What's more, I think this bug only happens on some types of hardware (some types of host controller).

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.)

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) wrote :

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) wrote :
Download full text (3.8 KiB)

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...

Read more...

Martin Lubich (mlubich) wrote :

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) wrote :

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) wrote :

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).

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

Please attach the dmesg log from a kernel built with CONFIG_USB_DEBUG enabled. If possible, make it a 2.6.27-rc8 kernel.

Created attachment 18230
dmesg dump

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

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?

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.

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?

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.

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Here is another confirmation that things are as horrible as they ever were after an update to Intrepid RC.

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

> 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) wrote :

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) wrote :

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.

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) wrote :

Open source EPIC FAIL.

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) wrote :

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) wrote :

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!

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) wrote :

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) wrote :

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) wrote :

Hello,

My issue has been solved with this "trick" taken from https://bugs.launchpad.net/ubuntu/+source/udev/+bug/221983

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

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.

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...

Changed in linux-source-2.6.20:
status: New → Won't Fix
Changed in linux:
status: Won't Fix → New
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
status: New → Confirmed
Changed in linux-source-2.6.22:
status: New → Won't Fix
Changed in linux-source-2.6.20:
importance: Undecided → High
Tobias Brandt (tobiasbrandt) wrote :

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.

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

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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
/ \

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

i forgot:
intrepid ibex
Linux Pearl 2.6.27-10-generic

archdrone (archdrone) wrote :

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) wrote :

oops, im in wrong ehci-hcd bug thread, sorry

Thanks archdrone, i have to move o delete my report? i don't want to generate chaos

archdrone (archdrone) wrote :

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) wrote :

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...

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) wrote :

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) wrote :

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) wrote :

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.

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

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) wrote :

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.

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

Changed in linux:
status: Unknown → Invalid

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) wrote :

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 :)

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?

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) wrote :

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)

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) 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 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) wrote :

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) wrote :

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) wrote :

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!

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.

description: updated
Tim Penhey (thumper) wrote :

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) wrote :

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) wrote :

David, please attach lspci -vvnn and lsusb. Do you have an Alcor chipset ? can you unplug it and try again ?

David Becker (becker-david) wrote :

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) wrote :
David Becker (becker-david) wrote :

Whoops, the previous 'lsusb -v' is secretly just an 'lsusb'.

Here's the verbose version.

David Becker (becker-david) wrote :

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) wrote :

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

David Becker (becker-david) wrote :
Peter Hoeg (peterhoeg) wrote :

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?

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) wrote :

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.

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) wrote :

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.

@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) wrote :

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) wrote :
  • lspci.log Edit (6.7 KiB, text/x-log; name="lspci.log"; charset="UTF-8")

My hardware is near-identifcal to zasq's; same bug.

lspci attached.

David Becker (becker-david) wrote :

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

@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...

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) wrote :

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) wrote :
  • lsusb.log Edit (684 bytes, text/x-log; name="lsusb.log"; charset="UTF-8")

> 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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :
zasq (zasq) wrote :

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) wrote :

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) wrote :
Download full text (4.1 KiB)

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...

Read more...

Forest Bond (forest-bond) wrote :

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) wrote :

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) wrote :

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) wrote :

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) 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.)

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

> 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.

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) wrote :

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) wrote :

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.

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.

Changed in linux:
status: Confirmed → Fix Committed
status: New → Incomplete
Peter Hoeg (peterhoeg) wrote :

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) wrote :

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) wrote :

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?

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.

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.

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) wrote :

Not only alcor chipset, even my nforce2 has this problem

Stefano_PG (slot) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

Try reinstalling the 2.6.27-7, I removed it after the update to -9 and now it works like before.

Stefano_PG (slot) wrote :

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) wrote :

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.

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.

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) wrote :

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) wrote :

>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) wrote :

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) wrote :

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 :-)

>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.

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) wrote :

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) wrote :

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) wrote :

> 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) wrote :

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) 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.

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) wrote :

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.

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) wrote :

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.

Changed in linux:
status: Fix Committed → Confirmed
Stefano_PG (slot) wrote :

Look here: http://bugzilla.kernel.org/show_bug.cgi?id=11030

They say:

status:rejected
resolution:invalid

cnj5 (ubuntu-bugs-cjlj) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

Sorry, it resets.

This workaround does not work, the only thing to do is to rmmod ehci-hcd.

ezoltan (enzoltan) wrote :

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) wrote :

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
...