Bug 2725 - USB Hub problem
Summary: USB Hub problem
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Alan Stern
Depends on:
Blocks: USB
  Show dependency tree
Reported: 2004-05-18 13:11 UTC by Menaka Lashitha Bandara
Modified: 2005-08-18 16:26 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.6
Tree: Mainline
Regression: ---

dmesg-2.6.2 (14.74 KB, text/plain)
2004-06-05 19:07 UTC, Menaka Lashitha Bandara
dmesg-2.6.3 (14.77 KB, text/plain)
2004-06-05 19:10 UTC, Menaka Lashitha Bandara
dmesg-2.6.4 (14.75 KB, text/plain)
2004-06-05 19:11 UTC, Menaka Lashitha Bandara
dmesg-2.6.5 (14.73 KB, text/plain)
2004-06-05 19:12 UTC, Menaka Lashitha Bandara
dmesg-2.6.7 (10.13 KB, text/plain)
2004-06-17 01:10 UTC, Menaka Lashitha Bandara
Dmesg of (15.19 KB, text/plain)
2004-10-02 12:52 UTC, Menaka Lashitha Bandara
Use Microsoft-style device initialization (4.69 KB, patch)
2004-10-06 08:35 UTC, Alan Stern
Details | Diff

Description Menaka Lashitha Bandara 2004-05-18 13:11:39 UTC
Distribution: Debian Unstable

Hardware Environment: Apple ibook2 laptop, 600MHz, 384MB Ram, Macally
Perhipherals Macally Dotmouse.

Software Environment: Linux 2.6.6 on Debian Unstable PPC, X4.3, XFS filesystems.

Problem Description:
I get this dumped sometimes when I plug my mouse in and out:

usb 1-1: new low speed USB device using address 12
usb 1-1: unable to read config index 0 descriptor
usb 1-1: can't read configurations, error -84
usb 1-1: new low speed USB device using address 13
usb 1-1: device descriptor read/all, error 2

* More specifically plugging it out:

drivers/usb/input/hid-core.c: can't resubmit intr, 0001:01:19.0-1/input0, status -19

* Plugging it in again:

usb 1-1: new low speed USB device using address 14
usb 1-1: device descriptor read/all, error 2
usb 1-1: new low speed USB device using address 15
usb 1-1: unable to read config index 0 descriptor
usb 1-1: can't read configurations, error -84

This problem is non-existant on 2.4.21 with  benh + xfs patches, and 2.6.0-test9
with benh patches.

Steps to reproduce:

Simply plugging in my USB mouse, and sometimes get this, and other times it
works okay. It's quite wierd. Generally, I have to keep plugging it in and out a
couple of times for it to pick up.
Comment 1 Greg Kroah-Hartman 2004-05-20 09:26:24 UTC
Alan, this might be due to the config read logic changing?
Comment 2 Alan Stern 2004-05-20 11:03:55 UTC
This is not related to the config parsing logic; it occurs earlier, while
reading the device or configuration descriptors.  Error -84 is EILSEQ, which
means that the mouse's USB hardware generated a low-level protocol error.  Error
2 means here that the system tried to read an 18-byte device descriptor and
received only 2 bytes in response.  That's a little suspicious, since the data
is transmitted in 8-byte packets and so 2 bytes would be the expected size of
the last packet.  I don't know what to make of that.

I'm tempted to say this is a hardware problem in the mouse, but that doesn't
explain why it works with the older kernels.  Going from 2.6.0 to 2.6.6 is a big
jump.  Could you try running some of the intermediate kernel versions, to pin
down at which step the error started to occur?
Comment 3 Menaka Lashitha Bandara 2004-06-02 20:59:21 UTC
I have tested this mouse on my x86 box. It is a 400MHz AMD, and has USB:
USB Universal Host Controller Interface driver v2.2
uhci_hcd 0000:00:07.2: VIA Technologies, Inc. USB
uhci_hcd 0000:00:07.2: irq 10, io base 0000e400
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected

When I plug this mouse into this system, it doesn't have any problems. I would
say that the problem is likely to do with the ohci driver handles the Apple
Motherboard. The output from my x86 on plugging in the mouse (many times,
without failure it works! - although initially I didn't have usbhid loaded!):

usb 1-2: new low speed USB device using address 2
usb 1-2: USB disconnect, address 2
usb 1-1: new low speed USB device using address 3
usb 1-1: USB disconnect, address 3
usb 1-2: new low speed USB device using address 4
usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Macally Peripherals  Macally DotMouse] on
usbcore: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
usb 1-2: USB disconnect, address 4
usb 1-1: new low speed USB device using address 5
input: USB HID v1.10 Mouse [Macally Peripherals  Macally DotMouse] on
usb 1-1: USB disconnect, address 5
Comment 4 Menaka Lashitha Bandara 2004-06-02 21:02:39 UTC
This is the ohci usb driver initialising. I've extracted it from my dmesg:
ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
PCI: Enabling device 0001:01:18.0 (0000 -> 0002)
ohci_hcd 0001:01:18.0: Apple Computer Inc. KeyLargo/Pangea USB
ohci_hcd 0001:01:18.0: irq 27, pci mem d9844000
ohci_hcd 0001:01:18.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Enabling device 0001:01:19.0 (0000 -> 0002)
ohci_hcd 0001:01:19.0: Apple Computer Inc. KeyLargo/Pangea USB (#2)
ohci_hcd 0001:01:19.0: irq 28, pci mem d98ad000
ohci_hcd 0001:01:19.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected

In contrast to my x86 usb, this seems to get allocated 2 IRQ's, and it seems to
be initialising twice. Is this normal (I'm not sure of this hardware stuff, just
trying to spot some differences).
Comment 5 Alan Stern 2004-06-03 07:37:43 UTC
The OHCI driver gets 2 IRQs and initializes twice because your Apple has two
OHCI controllers!  So that part is normal.

Certainly the error you are seeing has nothing to do with the config parsing
code, since it works on x86.  Undoubtedly this is a problem with the OHCI driver
running on the Apple platform.

I'll try asking someone who knows more the Apple drivers about that to look at this.
Comment 6 Benjamin Herrenschmidt 2004-06-03 15:23:40 UTC
I don't see anything special off-hand, this is the good old built-in
OHCI apple used on all models for ages (they are using a NEC EHCI on
recent ones, but not on this iBook).

Could be a different issue too that happens to side effect into that
problem, like a missing memory barrier in the driver, difficult to
say at this point.
Comment 7 Menaka Lashitha Bandara 2004-06-03 20:32:02 UTC

What exactly would you need to debug this? I can send you any info you request.
I might add that this works perfectly with 2.6.0-test9 with your patches. (I
know that was ages ago, but anyway...).
Comment 8 Menaka Lashitha Bandara 2004-06-05 19:07:27 UTC
Created attachment 3085 [details]
Comment 9 Menaka Lashitha Bandara 2004-06-05 19:10:00 UTC
I've put attachments for the dmesg of 2.6.2-> 2.6.5. This problem seems to
emerge severely from 2.6.4 to 2.6.5, although there are wierd messages from the
input layer. I'll also be putting up the dmesg for 2.6.0 and 2.6.1 later. I'm
about to compile these kernels at the momement.
Comment 10 Menaka Lashitha Bandara 2004-06-05 19:10:48 UTC
Created attachment 3086 [details]
Comment 11 Menaka Lashitha Bandara 2004-06-05 19:11:17 UTC
Created attachment 3087 [details]
Comment 12 Menaka Lashitha Bandara 2004-06-05 19:12:01 UTC
Created attachment 3088 [details]
Comment 13 Alan Stern 2004-06-06 08:16:54 UTC
Even for 2.6.2 your log shows the mouse detaching and attaching multiple times.
 This isn't normal behavior, unless you really did unplug it and replug it
several times.  Did you?
Comment 14 Menaka Lashitha Bandara 2004-06-06 08:24:53 UTC
I should have explained that the messages from usb in the demsg's that I've
given, I __did__ remove and plug the mouse multiple times. As you can see from
the 2.6.5 output, usb doesn't respond well to puggling in and removing and
re-plugging in. The 2.6.2  picks the mouse up all the time, but the input layer
says something about losing intr. But, just to emphasise, I've carried out the
experiment by removing and plugging in many times, to see what sort of behaviour
I get from hub and input.
Comment 15 Menaka Lashitha Bandara 2004-06-17 01:10:38 UTC
Created attachment 3191 [details]

This bug is persistent even in 2.6.7 as well. There are more errors about some
descriptor that is  not read properly.
Comment 16 Benjamin Herrenschmidt 2004-06-17 09:31:35 UTC
Hrm... I wonder if those "remote wakeup" messages are correct ...

Well, at this point I just don't know, this should be dealt with the
USB folks, there is definitely something wrong in the driver. I'll
do a new pass over it checking for possible missing barriers, but
that's all I can do for now, I'm too busy and can't reproduce here
Comment 17 Alan Stern 2004-06-17 13:24:27 UTC
David Brownell says the "remote wakeup" messages really should be just "wakeup"
and that it's an unrelated problem.

So the mouse works okay in 2.6.0-test9 but not 2.6.2.  Have you tried
2.6.0-final and 2.6.1?
Comment 18 Menaka Lashitha Bandara 2004-06-17 15:45:52 UTC
The mouse works upto kernel 2.6.4. THat is, it works in 2.6.0 - 2.6.4. If you
look at the attachments I've sent, there are some wierd messages in kernels <
2.6.5, but the problem becomes really severe in 2.6.5. It's a real trick to get
the mouse working in 2.6.5, and 2.6.6. After plugging and unplugging a number of
times it sometimes work. It doesn't work at all in 2.6.7.

In 2.6.7, the problem isn't the "remote_wakeup", but it reports that it was
expecting 9 bytes but got 0.
Comment 19 David Brownell 2004-07-10 08:23:20 UTC
If this happens in the latest 2.6.7-bk, try posting results 
of the failed enumeration with CONFIG_USB_DEBUG. 
I'm suspecting the "remote" (not!) wakeup message may 
be on a problem codepath.  The message involves 
OHCI resuming root hubs that were "suspended because 
idle"; which it didn't do that before about 2.6.6.  And in 
the same way, it now uses INTR_RD ... that message 
means both mechanisms kicked in at once, which could 
trigger pm-related chip quirks. 
You can disable that "autosuspend" mechanism by 
configuring without CONFIG_PM. 
If CONFIG_PM matters, then I know something simple to try. 
But I don't think that could explain any of the problems 
before about 2.6.6 kernels. 
Comment 20 Alan Stern 2004-07-12 07:41:38 UTC
Try applying this patch:


It fixes a PPC-related bug that has been present in the UHCI driver since 2.6.6.
Comment 21 Menaka Lashitha Bandara 2004-07-23 17:15:07 UTC
Alan, the patch you recommended affects uhci. The problem here is with the ohci
driver, I don't see how it will be relavent. 
Comment 22 Menaka Lashitha Bandara 2004-10-02 12:52:33 UTC
Created attachment 3754 [details]
Dmesg of

Sorry I haven't submitted anything useful for this bug for a while. I havn't
had time to deal with this. This is a new dmesg from, with all the USB
debug stuff compiled in. I have had to plug the mouse in and out a few
times,and it picked it up. I hope this helps.
Comment 23 Alan Stern 2004-10-06 08:35:53 UTC
Created attachment 3770 [details]
Use Microsoft-style device initialization

Try using this patch with  It changes the way USB devices are
initialized to be more like the way Windows does it.
Comment 24 David Brownell 2005-04-04 17:15:23 UTC
Does it happen with 2.6.12-rc2? 
The descriptor read issues may well have been addressed with 
several patches that check for common descriptor read errors 
and then retry.  Seems lots of hardware (and sometimes even 
firmware) misbehaves there, given a chance. 
Comment 25 Greg Kroah-Hartman 2005-08-18 16:26:39 UTC
If this happens on 2.6.13-rc6 or greater, please reopen.

Note You need to log in before you can comment on or make changes to this bug.