On Fri, 8 Dec 2006, Ethan Romander wrote:

> I have tried both the 2.6.17 and 2.6.18 linux kernels and both give the
> message:
> 
> "reset low speed USB device using ohci_hcd and address X"
> 
> every few minutes in the system logs.  The "X" is, of course, a numeral
> and corresponds to my USB keyboard.  The device resets are accompanied
> by a delayed keyboard response and then the key pressed is repeated
> several (25, maybe) times.  Inbetween device resets, the keyboard
> operates completely normally.  The keyboard is the only device on the
> USB bus.
> 
> I found someone else who noticed this problem with the 2.6.19 linux
> kernel and posted to the linux-kernel mailing list.  The thread can be
> found here: 
> http://www.gossamer-threads.com/lists/linux/kernel/709839#709839 .  The
> poster does not seem to have achieved resolution of the issue.
> 
> Following the suggestions at the end of the linux-kernel thread, I
> turned on CONFIG_USB_DEBUG.  No additional information is emitted by
> the kernel during a reset event.  In addition, I used usbmon to capture
> bus activity during a reset event.  usbmon gave the following trace:
...

See below.

> Note that in this trace the keyboard is device 7.  Also, this trace was
> captured by allowing the machine to sit idle, waiting for a device
> reset (i.e. no keys were pressed, nothing was touched).
> 
> Hardware details are as follows:  Both the linux-kernel poster and I
> have nVidia chipsets:
> 
> $lspci -nn
> 00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller
> [10de:005a] (rev a2)
> 00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller
> [10de:005b] (rev a3)
> 
> The linux-kernel poster and I have different keyboards.  Mine is a
> Logitech Media Elite:
> 
> $lsusb
> Bus 001 Device 007: ID 046d:c30f Logitech, Inc.
> 
> I have tried a different, non-Logitech USB keyboard (one with fewer
> extra buttons) and did not experience any device resets.
> 
> Both the linux-kernel poster and I are using our keyboards on a USB 1.0
> bus controlled by the ohci_hcd driver.
> 
> Can anyone provide any insight?  What is happening in the usbmon trace?

Here's a detailed explanation of the usbmon trace.  It's mostly a lot of 
uninteresting technical details that don't have much to do with your 
problem.

Note that the timestamps are in the second column, with a missing decimal
point after the 4th digit.  For example, the first timestamp is really at
3741.485036 seconds.

> ffff81015cabd200 3741485036 C Ii:007:01 0 8 = 00000000 00000000

The keyboard sent some data on interface 1, probably indicating that no
keys were pressed.

> ffff81015cabd200 3741485053 S Ii:007:01 -115 8 <

The computer asked the keyboard for the next event on interface 0.

> ffff81015cabda40 3838186011 C Ii:007:02 -110 0

A USB communications error occurred when the kernel polled the keyboard 
for events on interface 1.  Note that this occurred 97 seconds after the 
previous event.

> ffff81015cabd200 3838187009 C Ii:007:01 -2 0

The kernel cancelled its request for the next event on interface 0, in
preparation for the upcoming reset.

> ffff81015cabd500 3838187021 S Co:001:00 s 23 03 0004 0001 0000 0
> ffff81015cabd500 3838250569 C Co:001:00 0 0

The kernel told the USB controller to reset port 1 and it acknowledged.
This isn't supposed to happen after only one error.  The fact that it did 
suggests where the problem lies: The error counter doesn't get reset 
properly when there's a long time interval between errors.

> ffff81007f499740 3838306573 C Ii:001:01 0 2 = 0200
> ffff81007f499740 3838306577 S Ii:001:01 -115 2 <
The kernel asked the keyboard for its device descriptor and the keyboard 
replied.

The USB controller reported an event on port 1 and the kernel asked it for 
the next event.

> ffff81015cabd8c0 3838454569 S Ci:001:00 s a3 00 0000 0001 0004 4 <
> ffff81015cabd8c0 3838454573 C Ci:001:00 0 4 = 03031000

The kernel asked the USB controller for the status of port 1 and the 
controller replied that there had been a reset-change.

> ffff81015cabd980 3838510567 S Co:001:00 s 23 01 0014 0001 0000 0
> ffff81015cabd980 3838510571 C Co:001:00 0 0

The kernel told the USB controller to turn off the reset-change 
notification.

> ffff810033f3a9c0 3838510584 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> ffff810033f3a9c0 3838513004 C Ci:000:00 0 18 = 12011001 00000008
> 6d040fc3 00230102 0001

The kernel asked the keyboard for its device descriptor and the keyboard 
replied.

> ffff810033f3a9c0 3838513011 S Co:001:00 s 23 03 0004 0001 0000 0

The kernel told the USB controller to reset port 1 again.

> ffff81007f499740 3838558570 C Ii:001:01 0 2 = 0200
> ffff81007f499740 3838558574 S Ii:001:01 -115 2 <

The USB controller reported an event on port 1 and the kernel asked it for 
the next event.

> ffff810033f3a9c0 3838578565 C Co:001:00 0 0

The USB controller acknowledged the command to reset port 1.

> ffff810033f3a9c0 3838782566 S Ci:001:00 s a3 00 0000 0001 0004 4 <
> ffff810033f3a9c0 3838782571 C Ci:001:00 0 4 = 03031000

The kernel asked the USB controller for the status of port 1 and the 
controller replied that there had been a reset-change.

> ffff81007f499740 3838810567 C Ii:001:01 0 2 = 0200
> ffff81007f499740 3838810571 S Ii:001:01 -115 2 <

The USB controller reported an event on port 1 and the kernel asked it for 
the next event.

> ffff810033f3a9c0 3838838563 S Co:001:00 s 23 01 0014 0001 0000 0
> ffff810033f3a9c0 3838838567 C Co:001:00 0 0

The kernel told the USB controller to turn off the reset-change 
notification.

> ffff810033f3a9c0 3838838571 S Co:000:00 s 00 05 0007 0000 0000 0
> ffff810033f3a9c0 3838839997 C Co:000:00 0 0

The kernel told the keyboard that it should set its USB address to 7
and the keyboard acknowledged.

> ffff81015cabd2c0 3838858565 S Ci:007:00 s 80 06 0100 0000 0012 18 <
> ffff81015cabd2c0 3838860996 C Ci:007:00 0 18 = 12011001 00000008
> 6d040fc3 00230102 0001

The kernel asked the keyboard for its device descriptor and the keyboard 
replied.

> ffff810033f3a9c0 3838861004 S Ci:007:00 s 80 06 0200 0000 003b 59 <
> ffff810033f3a9c0 3838865996 C Ci:007:00 0 59 = 09023b00 020100a0
> 32090400 00010301 01000921 10010001 22400007 05810308

The kernel asked the keyboard for its first configuration descriptor and 
the keyboard replied.

> ffff810033f3a9c0 3838866002 S Co:007:00 s 00 09 0001 0000 0000 0
> ffff810033f3a9c0 3838868995 C Co:007:00 0 0

The kernel told the keyboard to install configuration 1 and the keyboard 
acknowledged.

> ffff810033f3a9c0 3838869001 S Co:007:00 s 01 0b 0000 0000 0000 0
> ffff810033f3a9c0 3838871994 C Co:007:00 0 0

The kernel told the keyboard to install altsetting 0 for interface 0 and 
the keyboard acknowledged.

> ffff810033f3a9c0 3838872100 S Co:007:00 s 01 0b 0000 0001 0000 0
> ffff810033f3a9c0 3838874996 C Co:007:00 0 0

The kernel told the keyboard to install altsetting 0 for interface 1 and 
the keyboard acknowledged.

> ffff810033f3a9c0 3838875084 S Co:007:00 s 21 0a 0000 0001 0000 0
> ffff810033f3a9c0 3838877995 C Co:007:00 0 0

The kernel told the keyboard to set its "idle delay" for interface 1 to 0 
(i.e., the keyboard shouldn't send reports if no key presses or releases 
have happened) and the keyboard acknowledged.

> ffff81015cabda40 3838878003 S Ii:007:02 -115 3 <

The kernel asked the keyboard for the next event on interface 1.

> ffff810033f3a9c0 3838878009 S Co:007:00 s 21 0a 0000 0000 0000 0
> ffff810033f3a9c0 3838880995 C Co:007:00 0 0

The kernel told the keyboard to set its "idle delay" for interface 0 to 0 
and the keyboard acknoweledged.

> ffff81015cabd200 3838881001 S Ii:007:01 -115 8 <

The kernel asked the keyboard for the next event on interface 0.

> ffff81015cabd200 3843130907 C Ii:007:01 0 8 = 01000000 00000000

The keyboard reported an event (probably some sort of keypress) on 
interface 0.

> ffff81015cabd200 3843130921 S Ii:007:01 -115 8 <

The kernel asked the keyboard for the next event on interface 0.

>  I'm just about at the end of my technical ability troubleshooting
> this, but I'm happy to provide additional information to more capable
> individuals.

Try out the patch below (it should apply to 2.6.18 or 2.6.19) and see if 
it helps.

Alan Stern



Index: usb-2.6/drivers/usb/input/hid-core.c
===================================================================
--- usb-2.6.orig/drivers/usb/input/hid-core.c
+++ usb-2.6/drivers/usb/input/hid-core.c
@@ -1021,6 +1021,11 @@ static void hid_io_error(struct hid_devi
        if (usb_get_intfdata(hid->intf) == NULL)
                goto done;
 
+       /* If it has been at least 2 seconds since the last error, we'll
+        * assume this a brand new error and reset the delay counter. */
+       if (time_after(jiffies, hid->stop_retry + 2*HZ))
+               hid->retry_delay = 0;
+
        /* When an error occurs, retry at increasing intervals */
        if (hid->retry_delay == 0) {
                hid->retry_delay = 13;  /* Then 26, 52, 104, 104, ... */


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to