Bug 2725

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.