On Fri, 2 Mar 2007, Gordon Messmer wrote: > Alan Stern wrote: > > On Thu, 1 Mar 2007, Gordon Messmer wrote: > > > >> Here's an aspect that I'd completely forgotten in the last year. > >> Occasionally the mouse is assigned a different ID (I think?), and then > >> stops causing resets. > >> > >> Mar 1 05:40:28 herald kernel: usb 2-1: reset low speed USB device using > >> uhci_hcd and address 3 > >> <snip much of the same> > >> Mar 1 06:11:39 herald kernel: usb 2-1: failed to restore interface 0 > >> altsetting 0 (error=-71) > >> Mar 1 06:11:39 herald kernel: usb 2-1: USB disconnect, address 3 > >> Mar 1 06:11:39 herald kernel: usb 2-1: new low speed USB device using > >> uhci_hcd and address 4 > >> Mar 1 06:11:39 herald kernel: usb 2-1: configuration #1 chosen from 1 > >> choice > >> Mar 1 06:11:39 herald kernel: input: Logitech USB Mouse as > >> /class/input/input3 > >> Mar 1 06:11:39 herald kernel: input: USB HID v1.10 Mouse [Logitech USB > >> Mouse] on usb-0000:00:1d.1-1 > > > > I don't think this is related to anything. It's probably just a > > coincidence. > > The mouse triggers resets at a steady, consistent interval. Once in a > while the kernel fails to "restore interface", and assigns the device a > new address. Afterward there are no resets. Surely that's relevant? :)
Maybe it is. I can't tell from what you've posted so far. Keep in mind, however, that doing a reset and assigning a new address both amount (from the point of view of the mouse) to almost the same thing as unplugging and replugging. The only significant difference is that there's no loss of power. > >> This appears in usbmon during each reset: > >> > >> f7e67b40 2881999053 C Ii:003:01 -84 0 > >> f7e67b40 2882012282 S Ii:003:01 -115 4 < > >> f7e67b40 2891495532 C Ii:003:01 -84 0 > > > > Those three lines are an I/O error, a retry, and another I/O error 9.5 > > seconds later. > > Out of curiosity, what IO was in error? The mouse is idle prior to that > bit. If I use a "working" kernel, the line stays completely silent. > You mentioned that newer kernels try to detect problems that the old > ones ignored. Is the kernel probing the mouse to make sure it's still > there? Not to make sure it's still there -- to see whether you have moved it or pressed one of the buttons. That's how USB works: All communication is initiated by the host (the main computer). If you do start moving the mouse or pressing its buttons, you'll see everything you do reflected in the usbmon output. Did you really mean it that the earlier kernels don't generate those "-84" lines? I don't understand how that could be; the presence or absence of an I/O error shouldn't depend on the kernel version. Do you have any sort of CPU power saving (like cpufreq) enabled? > > From the fact that your two errors occurred more than 9 seconds apart, it > > seems that you are encountering some intermittent electrical or > > interference problem. > > ...except that it's not intermittent. When the system is resetting the > mouse, it does so at very predictable intervals (about every 90 seconds > with FC6's latest kernel). Another reason to think there may be a systematic cause, something that interferes with the USB controller periodically. But it isn't anything in the USB stack. Can you post a longer usbmon log, one that includes several of those 90-second intervals? With or without the patch, or maybe even one of each. Alan Stern ------------------------------------------------------------------------- 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
