On Sat, 6 Jul 2013, Larry Keegan wrote:
> Just a thought, but has the way the kernel 'sets-up' a USB mouse
> changed over the months? I mean in a way which would mean different
> numbers in the above usbmon trace? What I'm wondering is if the newer
> kernel could be eeking out different bugs in the mouse's software, and
> that is provoking the disconnect. Is that possible? Or is it genuinely an
> electrical thing? I'm afraid I know zip about USB.
As far as I know, there haven't been any changes in the way a USB mouse
gets initialized. Besides, even if there were, I have never heard of
any setting that would tell the mouse to disconnect itself every 62
seconds! :-)
> > > The other thing which makes me feel that power and EMI are unlikely
> > > to be the cause of the problem is the precise nature of the events.
> > > Here is a snippet from my syslog:
> > >
> > > # tail -f /var/log/messages | grep 'USB disconnect'
> > > 2013-07-06T11:27:19.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 126
> > > 2013-07-06T11:28:21.518556Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 127
> > > 2013-07-06T11:29:23.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 2
> > > 2013-07-06T11:30:25.518562Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 3
> > > 2013-07-06T11:31:27.518568Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 4
> > > 2013-07-06T11:32:29.518567Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 5
> > > 2013-07-06T11:33:31.518568Z {0.6} ud1 kernel: usb 4-2: USB
> > > disconnect, device number 6
> > >
> > > These events occur with surprising regularity. Too regular for it
> > > to be an uncorrelated external event. Three mice, (two Microsoft,
> > > and one other) but all three containing the same PixArt chip all
> > > exhibit the same timing. If this were power droop I'd expect
> > > capacitor component tolerances to cause slightly different timings
> > > on the different mice, or different computers but they are
> > > microsecond perfect.
> >
> > Yes. Obviously this is related to a hardware or software timer. The
> > microsecond perfection may not mean anything, however. Is this bus
> > connected to a UHCI controller? The uhci-hcd driver uses a software
> > timer for detecting port-connect changes; the timer runs at a steady
> > rate of precisely 4 times per second.
>
> Ah ah. I thought the numbers were suspiciously regular. I suppose the
> mice, being 1.5Mbps devices will be connected to the UHCI. The ports
> are wired to the motherboard's Intel ICH7. The port is definitely also
> capable of speaking at 480Mbps.
You didn't say before that your motherboard was Intel. Other brands
use OHCI instead of UHCI, and the ohci-hcd driver uses hardware
interrupts rather than a software timer for detecting port-connect
changes.
> However, I'm not sure this explains the essentially-random behaviour of
> the most of the bus when the mouse is plugged into a USB 2.0 hub. In
With an external hub, the port-status packets are sent based on a
hardware timer that triggers 8 times per second, with great regularity.
> these cases it is my understanding that the controller is EHCI and the
> hub buffers these packets and sends them over the 480Mbps link as if
> they were 'normal' USB 2.0 packets. That implies the mouse is also
> electrically incompatible with my hubs. Umm. I'll look into this.
They aren't electically incompatible, or they wouldn't work at all.
But _something_ is causing them to disconnect.
> > You said the problems began on one of the computers when you upgraded
> > the kernel. Can you try using bisection to find the kernel change
> > that first triggered the problem?
>
> I'm recompiling as we speak.
This seems like the best approach. It wouldn't be surprising to find
that the problem's source lies in some totally unexpected area.
> Thank you very much for your help.
You're welcome.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
