On Sat, 6 Jul 2013 16:58:38 -0400 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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! :-) > > > 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. > Dear Alan, I've done some further testing and I don't think this can be linux thing. One of my tests was conducted on a machine which has lain dormant since 2009. It had a 2.6.28.6 kernel on it. It has never had a mouse plugged in before this test, but as it is identical to two of the other machines I use daily, I can't see why it wouldn't have worked in the past. The test failed in exactly the same way. I tried all the USB sockets and all the USB-related BIOS settings, all to no avail. In an attempt to rule out electrical noise I took my laptop (running 2.6.34 kernel) into a field far enough away from buildings and overhead lines not to be a problem, or so I thought. It didn't help. Can anyone on this list think of a reason why 3 wired mice might fail under these circumstances? I'll exclude government conspiracies. Yours, Larry. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
