Here is dmesg output showing my unloading/loading of hid and the subsequent 'lockup' of the mouse that followed.
drivers/usb/core/usb.c: deregistering driver hiddev drivers/usb/core/usb.c: deregistering driver hid ohci-hcd 0000:02:0e.0: shutdown urb f7587480 pipe 40408380 ep1in-intr usb 1-2: hcd_unlink_urb f7587480 fail -22 usb 1-2: hcd_unlink_urb f7587400 fail -22 usb 1-2: hcd_unlink_urb f7587480 fail -22
The HID driver is presumably unlinking that URB that just got killed, then unlinking it again, and again. Not the smartest things it could be doing, but thatshould be harmless.
drivers/usb/core/usb.c: registered new driver hiddev
hid 1-2:0: usb_probe_interface
hid 1-2:0: usb_probe_interface - got id
input: USB HID v1.00 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye?] on usb-0000:02:0e.0-2
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
All that looks fine ... but this next bit doesn't:
ohci-hcd 0000:02:0e.0: urb f7587480 path 2 ep1in 8e160000 cc 8 --> status -75
Quick translation: that URB showed up again. We _hope_ it's because it was freed and just "happened" to get re-allocated, that's a perfectly reasonable thing to happen.
A TD queued to that URB got condition code 8, "data overrun", as if more bytes got sent to it than were allowed. (Maybe the packet size was 8 bytes, and 12 bytes were sent.) Shouldn't happen; but not necessarily worrisome by itself.
ohci-hcd 0000:02:0e.0: bad entry fffffff0
And this one looks pretty bogus. It means that some bad TD landed in the "reversed donelist". How did that happen? Hard to say. If you're keen to find out, add some code to the dl_reverse_done_list() routine to show the queue it found; there may be a hint.
Of course that particular value looks odd too: ~0 with the four low order bits forced to zero ... as if the HC turned off all the bits used to address non-ISO TDs.
Nothing in the OHCI code should be using a value like ~0; OHCI usually treats zero as a null pointer, though I think some silicon may create ~0 out of thin air (I've seen that value in some registers).
It's been almost a year since I saw a "bad entry" diagnostic. At that time, it sure seemed like some other driver was smashing heap memory that OHCI used. So I made OHCI keep its hash chains more efficiently (also, no heap); and the problems vanished. FWIW.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
