On Mon, 12 Mar 2007, Jiri Slaby wrote: > Alan Stern napsal(a): > > On Mon, 12 Mar 2007, Jiri Slaby wrote: > > > >> Bisecting figured out the culprit: > >> Commit: 17230acdc71137622ca7dfd789b3944c75d39404 > >> Author: Alan Stern <[EMAIL PROTECTED]> Mon, 19 Feb 2007 15:52:45 -0500 > >> > >> UHCI: Eliminate asynchronous skeleton Queue Headers > [...] > > Post it along > > with the usbmon log, and I'll try to figure out what happened. > > Here it comes: > USBMON: > f7525b40 1832950485 C Ii:004:01 0 8 = 00005300 00000000 > f7525b40 1832950517 S Ii:004:01 -115 8 < > f7525140 1832950540 S Co:004:00 s 21 09 0200 0000 0001 1 = 01 > f7525140 1832952485 C Co:004:00 0 1 > > > Corresponds to numlock; 7; numlock; 7.
Actually that little piece corresponds just to pressing Numlock; it doesn't even include the key release. > UHCI snapshot: ... Leaving out the details, one thing is striking. The usbmon trace shows an interrupt URB submitted for device 4 endpoint 1, but none of the URBs listed in the UHCI snapshot are for that device. Instead there are entries for device 7 (which appears to be a hub), device 8, and device 2 (which is low-speed, probably an HID device). Are you certain your UHCI snapshot was from the correct controller? It would help to see your /proc/bus/usb/devices. Otherwise it's hard to know what the various device numbers refer to. Also, it would help to see UHCI snapshots for both before and after you press Numlock. > Side note, it doesn't stop working at all, but there is something like > timeout > or whatever, after a while, the keyboard interacts again. I can't reproduce the problem on 2.6.21-rc3 with the UHCI patch applied. Can you try the same thing and see what happens? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
