ehci_hcd module causes I/O errors in USB 2.0 devices

[Al Buntu]

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

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

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

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

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

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

[Al Buntu (biedermann2)]

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

[Al Buntu (biedermann2)]

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

[Al Buntu (biedermann2)]

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

[Brian Murray (brian-murray)]

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

[Al Buntu (biedermann2)]

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

[magilus (magilus)]

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

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

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

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

(several times)

[magilus (magilus)]

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

Though, I will also attach my outputs.

[magilus (magilus)]

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

Al Buntu, which mainboard do you have?

[magilus (magilus)]

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

[Kyle McMartin (kyle)]

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

[Al Buntu (biedermann2)]

My Mainboard:

Asus A7N8X-(X?)
with NForce 2

Greetings,

Al Buntu

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

[magilus (magilus)]

fixed in 2.6.20-10

[magilus (magilus)]

reappeard in 2.6.20-12-generic

[Jared Sutton (jpsutton)]

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

[Mika Kukkonen (mikukkon)]

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

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

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

And the device gets shown on desktop etc.

More info available on request.

[magilus (magilus)]

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

[Mika Kukkonen (mikukkon)]

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

--MiKu

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

[Jared Sutton (jpsutton)]

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

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

[Mika Kukkonen (mikukkon)]

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

--MiKu

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

[Jared Sutton (jpsutton)]

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

[Mika Kukkonen (mikukkon)]

And with 2.6.20-14-generic too.

--MiKu

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

[John Zero (johnzero)]

Same issues. The command:

modprobe -r ehci_hcd

"helped" somewhet.

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

Asus A7N8X with NForce2 chipset

[stephg (stephg)]

Same issue on Dapper.

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

Works perfectly with 2.6.15-27

I also have an Asus A7N8X with NForce2 chipset

[TheLimper (thelimper-rogers)]

FYI:

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

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

[Mika Kukkonen (mikukkon)]

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

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

and that did not help either :-(

--MiKu

[John Zero (johnzero)]

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

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

[Mika Kukkonen (mikukkon)]

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

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

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

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

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

[stephg (stephg)]

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

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

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

[John Zero (johnzero)]

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

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

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

[ingo (rum-topf)]

Problem persists in Feisty

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

[Robert North (russetrob)]

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

Will attach log file, and hardware info later.

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

Created attachment 21743
Add Clear-TT-Buffer callback

Patch 1: modify the Clear-TT-Buffer interface by adding a callback pointer

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

Created attachment 21744
Make ehci-hcd wait for Clear-TT-Buffer to complete

Patch 2: Make ehci-hcd wait Clear-TT-Buffer requests to complete

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

i've the same issue. i'll try the patches ASAP.
thanks

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

i've tried them.
After 300mb of data movement i've see a "reset high speed" :( but it occurs only time...so i think i could say the patches fixed something but not all...i've tried on 2.6.30.2

If i could help let me know :)

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

Can you reproduce the reset? If you can't, then there's nothing to worry about. If you can, attach a usbmon log showing what happens starting shortly before the reset.

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

ok, i'll try it. Thanks for your work :)

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

i've created this file with usbmon during a moving the directory /usr/ on my ssd
after 40mb it gives me a reset
i've pressed CTRL-C ASAP i've seen the reset
i hope it can help you

here is the log: http://www.cagnulein.com/tmp/usbmon_ehci_reset.txt

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

Unfortunately the usbmon log doesn't show why the reset occurred. Apparently the computer was writing data to the disk when the disk suddenly stopped accepting data. After 30 seconds the computer gave up and and reset the disk drive, after which it started working normally again.

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

could it be an hardware problem? how can i verify this?

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

Sure it could. Verify it by trying out different hardware.

[kernel.org (kernel.org-linux-kernel-bugs)]

Also try a different cable.
And last but not least: try another non-linux OS (but don't ask me for suggestion;)

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

Most of these weird problems seem to occur if (and only if) I use a PCI USB controller plugged into a PCI-X slot of my IBM xSeries server.

Some facts:
* Tried two USB controllers, NEC and VIA.
* NEC works fine when only one mass storage device is plugged in. Resets occur otherwise.
* NEC doesn't like webcams. The image is either choppy or just black, varies from (kernel) version to version.
* VIA doesn't support mass storage at all. Numerous I/O errors pop up immediately when a device is connected.
* VIA supports webcams, but only at UHCI speeds. When a EHCI-only webcam is plugged in, it is detected, but doesn't work.

But here comes the most important fact of all: There are *no* such problems on other Linux machines I run. For example, USB now works fine on my laptop. I can connect my DVB-T receiver, pen drive, bluetooth dongle, webcam and other crazy devices at once and nothing bad happens.

Perhaps there's something wrong with PCI USB controllers in PCI-X slots. Unfortunately, the server is in use, so I can't bring it down and test USB thoroughly.

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

i've try the usb on another pc and works well.
so i've installed windows xp on the pc that has the problem.
TADAM: the problem still remains!

So it's an hardware issue :(

Thanks for your time

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

Greg, I don't think this bug report is helping anybody any more. We haven't heard anything from the OP in almost a year. You might as well close it out.

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

Ok, closing out, thanks.

[kernel.org (kernel.org-linux-kernel-bugs)]

I find the decision to close this bug quick and unfounded. Who has verified that the fix committed earlier has resolved this issue? It's not because the last person talking here said it was hardware-related that there was no bug. Ideally we should find a machine/configuration where this bug has happened, test without the fix, test with the fix, and then conclude.

Please read my comment #67 above. This bug has been occuring regularly and people report it mostly against distros bug tracking. Since distro can't do much they often close the report because they find it hard to track and do anything about it. This practice of closing bug because they're too elusive to track isn't right, even less in open source (what's the problem with how long a bug is open?)

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

(In reply to comment #84)
> I find the decision to close this bug quick and unfounded. Who has verified
> that the fix committed earlier has resolved this issue?

I did not see any reports of this problem with the latest Linux kernel.

If you do have this problem, with the 2.6.30 or later kernel, please post to the <email address hidden> mailing list the kernel log messages and we will be glad to work with you there.

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

(In reply to comment #84)
> I find the decision to close this bug quick and unfounded.

The bug report was opened more than a year ago. How can you call that "quick"?

Evidently you did not receive the message I sent to you in response to comment #67. The gist of it was that this is not a single bug. Most of the bug reports you cited were either non-reproducible or caused by hardware problems. In others the reporters have stopped responding, making it impossible to find out what was wrong.

So far there has been extremely little indication that errors in the software are responsible for these resets. Even if it is true that the software is partly to blame, we have no way to fix it unless we can find out exactly where the errors are. Errors get fixed when they are tracked down, and your rant doesn't contribute towards tracking down any of these problems.

[kernel.org (kernel.org-linux-kernel-bugs)]

(In reply to comment #86)
> (In reply to comment #84)
> > I find the decision to close this bug quick and unfounded.
> The bug report was opened more than a year ago. How can you call that
> "quick"?
I say quick as in quick-thinking.

> Evidently you did not receive the message I sent to you in response to
> comment #67. The gist of it was that this is not a single bug.
I did receive it, but I was just starting out with linux and couldn't really deal with kernel hacking, I needed to get going with my work.
> Most of the bug reports you cited were either non-reproducible or caused by
> hardware problems.
> In others the reporters have stopped responding, making it impossible to find
> out what was wrong.
That's what I call hard to track and elusive. Does that mean there's no bug? No. If there's a bug, even if hard to track, I think there should be an entry for it. All this talk about keeping a log only for reproducible bugs does not make sense to me, and only reflect a dislike for unreproducible bug.

> So far there has been extremely little indication that errors in the software
> are responsible for these resets.
How do you explain other OS had no issue in the same configuration?

> Even if it is true that the software is
> partly to blame, we have no way to fix it unless we can find out exactly
> where
> the errors are. Errors get fixed when they are tracked down, and your rant
> doesn't contribute towards tracking down any of these problems.
Closing this bug doesn't contribute in nailing it down. That's what happened for the last two years: it gets reported and then closed, it reappers somewhere else but the OP quickly disappears because this bug is a showstopper (you can't work with it).

Anyway, there's no need to consider this a rant and get personal about it. I appreciate a lot all the efforts from the so many people in getting GNU/Linux to where it is now. Also, bear in mind that in the past 4 years I really wanted to get away from M$. This bug kept me from making the move. Only recently did I try again, got this bug again, but did not want to get discouraged because of it. So I'm sorry for making so much noise, I'm tired of this bug as much as you are, but I don't want to forget about it.

Is the fix you talked about in 2.6.30? If so then it should be in my arch release kernel. I'll rewire my devices (in order to reproduce the bug) and report back in about a week when I have more time to play.

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

> That's what I call hard to track and elusive. Does that mean there's no bug?
> No. If there's a bug, even if hard to track, I think there should be an entry
> for it. All this talk about keeping a log only for reproducible bugs does not
> make sense to me, and only reflect a dislike for unreproducible bug.

If a bug isn't reproducible and can't be tracked then there is no hope of fixing it. In such cases, whether the bug report remains open or not doesn't really matter much.

> How do you explain other OS had no issue in the same configuration?

I can't explain it because I haven't been able to obtain enough information. Mostly this is because the reporters stop responding, but occasionally it's because special debugging hardware is needed and the reporter doesn't have it.

One possible explanation might be that the drivers for the other OS were written with special knowledge of some bugs in the hardware. Manufacturers often don't share such knowledge with open-source programmers. But I have no way to know if this is the case here.

> Closing this bug doesn't contribute in nailing it down. That's what happened
> for the last two years: it gets reported and then closed, it reappers
> somewhere
> else but the OP quickly disappears because this bug is a showstopper (you
> can't
> work with it).

You are making a very common mistake: confusing the bug with the bug report. I keep telling you that what we see reported here, in this one report, is really many different bugs. Several of them have already been tracked down and solved. You don't seem to understand this.

> Only recently did I
> try again, got this bug again, but did not want to get discouraged because of
> it. So I'm sorry for making so much noise, I'm tired of this bug as much as
> you
> are, but I don't want to forget about it.

If you would like to contribute, please open a new bug report. This is because your problem is almost certainly caused by a different bug from the one that originally led to this report.

> Is the fix you talked about in 2.6.30?

Only partially. The most recent code is available in 2.26.31-rc5 together with this patch: <http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.31-rc5.patch>.

[kernel.org (kernel.org-linux-kernel-bugs)]

I will wait for 2.6.31 to reach arch release then. I'll test before the new kernel, and then after. If the bug is still there, I'd be happy to help with the tracking, but I won't have time to deal with kernel hacking. I'd be happy to use whatever debug kernel that will work on my arch system if one cares to provide it.

I'll open a new bug report if needed and back link to this one because even if there are other bugs that got mingled, I find that most of the discussion here relates to the resets I experience with my keyboard and mouse.

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

Okay, good. Mostly what I object to is people jumping on board someone else's bug report, with their own bugs that are quite different from the one originally reported, merely because one of the symptoms is the same.

[kernel.org (kernel.org-linux-kernel-bugs)]

I came here because my mouse and keyboard become unusable (jumpy mouse, repeating keys) in various settings (tried 2 different hubs and different cables) and each time dmesg shows that keyboard and/or mouse get reset. Earlier in the thread keyboard and mouse were mentioned as well as resets so I thought it was a good place here.

Initially I reported my issue against ubuntu bug 124406 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406?comments=all). However this bug got closed because it was judged too messy. I felt this bug did not get the proper attention it deserved, so I came here because I thought the kernel team would be more able to deal with it. I entered comment #67 and also created another ubuntu bug entry (see https://bugs.launchpad.net/ubuntu/+bug/383722). There you'll find more info on what I experience along with relevant dmesg logs.

I understand your point except that in practice when a bug is difficult to track and reproduce it gets reported in many different ways, and there's not much we can do about that. I'm sorry to be so forthcoming but I'm tired of always seeing this bug getting dismissed in similar ways: can't reproduce, OP gone, confusion with other bugs... If we keep sticking to the rules of clean and reproducible bugs then we'll never become good at dealing with concurrency issues and parallel computing!

BTW: I can reproduce the bug and so does Rolf Leggewie (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124406/comments/254).

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

All right. We'll wait until you can install the latest kernel with all the existing patches and are able to do some testing. You will need to enable CONFIG_USB_DEBUG, CONFIG_USB_MON, and CONFIG_DEBUG_FS.

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

I'm thinking I've spot the particular USB configuration when the problem is present. It seems to be when copied large amount of data (say 1.9 GiB) from USB using SD-card reader. I've not check this time but it seems that it does not occure on dd of partition.

Reproduced on 2.6.30.4 - I'll check the -rc soon.

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

I were injured this problem too. When I install clean system 17.0 Linux mint all were OK. During some updates by 'Update manager' on 17.1 the problem were rised.

The hardware has not been changed

This is my post: http://askubuntu.com/questions/666601/system-is-loading-about-10-min-what-is-comming-on with messages on logs.

This problem does not exists when rebooting. It is only when cool start.

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

Linux keshome 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

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

updating to 3.16/4.1.3/4.2 has no any effect

Linux keshome 4.2.0-040200-generic #201508301530 SMP Sun Aug 30 19:31:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

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

KES777, do you know of a kernel version that worked okay? And can you attach the log messages to this bug report? The Ubuntu question has been removed.

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

Created attachment 189931
log file with problems

The log file where you can see problem:
[ 3222.072011] usb 1-2: new high-speed USB device number 59 using ehci-pci

When this problem occurs
the FF tabs with adobe flash player does not work ,whole FF is halted.
Also can not run VirtualBox guest OS
Also the theme on desktop is changed to some other theme

Cool start has always this problem.
Sometimes when rebooting there is no this problem.

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

It sounds like your computer has lots of problems, not just with USB. Have you checked to see if a BIOS update is available?

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

Booting from [linuxmint-17.1-cinnamon-64bit.iso](https://www.google.com.ua/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCcQFjABahUKEwjb96KftL3IAhVFBywKHZpiC4w&url=http%3A%2F%2Fwww.linuxmint.com%2Fedition.php%3Fid%3D172&usg=AFQjCNGhNbBoPHn7h7j5jLG6Cgrs3xpogA&sig2=EiLtHf60Iuqh6l7cX0WtJw) has no any of those problems.

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

If you know which kernel version works and which one doesn't work, you can use git bisect to find the cause of the problem.

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

I do not know how to use it, how to compile my own kernel, install etc.

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

Created attachment 190741
log files of different OSes caused and not caused by this problem

The OSes:
1. Windows 7
2. Windows XP
3. FreeBSD 9.3
are not affected by "new high-speed USB device number" problem. They works fine.
The FreeBSD 9.3 just report about some error for umass:

Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Retrying command
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted

4. cinnamon mint 15 (3.8.0-19-generic) works fine, but kern.log file is spamed by this messages:

Oct 21 13:54:17 kes-desktop kernel: [ 4260.504011] usb 1-2: new high-speed USB device number 34 using ehci-pci
Oct 21 13:54:17 kes-desktop kernel: [ 4260.572330] hub 1-0:1.0: unable to enumerate USB device on port 2
Oct 21 13:54:17 kes-desktop kernel: [ 4260.788218] hub 1-0:1.0: unable to enumerate USB device on port 2

5. ubuntu 12.04 also is not affected.

These has problems:
1. ubuntu 14.04. It is loading too slow and after loading I can not visit sites that uses adobe_flash plugin. The browser is halted (see print_screen: ubuntu-14.04-ishalted.png).

2. cinnamon-mint-16
3. Fresh installation of 17.1

I also want to check how work mint 14 and 13, but I can not install them due to the installer error

The detailed log messages for those systems see at attachment

It seems some bug is introduced to the new kernels. If someone give me detaided instructions how to use bisect and how to compile/install kernels from source I can complete that.
Thank you.

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

There are lots of tutorials explaining how to use git bisect and how to build/install kernels. Google is your friend.

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

Thanks guys, I’ve been looking for this information for a long time, I'm glad to join your community. https://www.19216811ip.mobi

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

I am from Alberta, Canada. I am really happy to be a member of this forum. thanks.

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

Hello, I'm Marieromig We will help you get into your Router Login or other devices on your network. 192.168.1.250 is a private IP address used for local networks. After that, you face any issues so you can Call us at + 1-844-726-2255 visit : https://my-wifiextnet.net/genie-setup/

[Mywifiextsetupus (mywifiextsetupus-linux-kernel-bugs)]

log files of different OSes caused and not caused by this problem

The OSes:
1. Windows 7
2. Windows XP
3. FreeBSD 9.3
are not affected by "new high-speed USB device number" problem. They works fine.
The FreeBSD 9.3 just report about some error for umass:

Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Retrying command
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
Oct 18 00:30:23 kernel: (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted

4. cinnamon mint 15 (3.8.0-19-generic) works fine, but kern.log file is spamed by this messages:

Oct 21 13:54:17 kes-desktop kernel: [ 4260.504011] usb 1-2: new high-speed USB device number 34 using ehci-pci
Oct 21 13:54:17 kes-desktop kernel: [ 4260.572330] hub 1-0:1.0: unable to enumerate USB device on port 2
Oct 21 13:54:17 kes-desktop kernel: [ 4260.788218] hub 1-0:1.0: unable to enumerate USB device on port 2

5. ubuntu 12.04 also is not affected.

These has problems:
1. ubuntu 14.04. It is loading too slow and after loading I can not visit sites that uses adobe_flash plugin. The browser is halted (see print_screen: ubuntu-14.04-ishalted.png).

2. cinnamon-mint-16
3. Fresh installation of 17.1

I also want to check how work mint 14 and 13, but I can not install them due to the installer error

The detailed log messages for those systems see at attachment

It seems some bug is introduced to the new kernels. If someone give me detaided instructions how to use bisect and how to compile/install kernels from source I can complete that.
Thank you.