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.
Alan, this might be due to the config read logic changing?
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?
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 usb-0000:00:07.2-2 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-0000:00:07.2-1 usb 1-1: USB disconnect, address 5
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).
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.
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.
Ben. 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...).
Created attachment 3085 [details] dmesg-2.6.2
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.
Created attachment 3086 [details] dmesg-2.6.3
Created attachment 3087 [details] dmesg-2.6.4
Created attachment 3088 [details] dmesg-2.6.5
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?
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.
Created attachment 3191 [details] dmesg-2.6.7 This bug is persistent even in 2.6.7 as well. There are more errors about some descriptor that is not read properly.
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 anyway.
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?
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.
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.
Try applying this patch: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108931259531482&q=raw It fixes a PPC-related bug that has been present in the UHCI driver since 2.6.6.
Alan, the patch you recommended affects uhci. The problem here is with the ohci driver, I don't see how it will be relavent.
Created attachment 3754 [details] Dmesg of 2.6.8.1 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 2.6.8.1, 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.
Created attachment 3770 [details] Use Microsoft-style device initialization Try using this patch with 2.6.8.1. It changes the way USB devices are initialized to be more like the way Windows does it.
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.
If this happens on 2.6.13-rc6 or greater, please reopen.