On Wed, 13 Aug 2014, David Laight wrote: > We are seeing some transient USB disconnects, these cause serious grief > if we use the xhci driver, so the ports are all forced to use ehci (bios config). > Even with ehci they are slightly problematic, partially resolved by using a > 'bond' interface to stop the ethernet interface and address disappearing. > > The hardware is a custom board containing an smsc95xx hub+ethernet. > > The kernel trace just shows (at about 4am): > [39203.215205] hid-generic 0003:03F0:034A.0004: can't reset device, 0000:00:1d.0-1.5.4/input1, status -71 > [39203.223659] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.232065] hid-generic 0003:03F0:034A.0003: can't reset device, 0000:00:1d.0-1.5.4/input0, status -71 > [39203.236024] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.241057] hid-generic 0003:03F0:034A.0004: can't reset device, 0000:00:1d.0-1.5.4/input1, status -71 > [39203.244019] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.254161] hid-generic 0003:03F0:034A.0003: can't reset device, 0000:00:1d.0-1.5.4/input0, status -71 > [39203.258132] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.263274] hid-generic 0003:03F0:034A.0004: can't reset device, 0000:00:1d.0-1.5.4/input1, status -71 > [39203.266120] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.276519] hid-generic 0003:03F0:034A.0003: can't reset device, 0000:00:1d.0-1.5.4/input0, status -71 > [39203.280479] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.286082] hid-generic 0003:03F0:034A.0004: can't reset device, 0000:00:1d.0-1.5.4/input1, status -71 > [39203.288342] usb 2-1.5: USB disconnect, device number 3 > [39203.288347] usb 2-1.5.1: USB disconnect, device number 4 > [39203.290948] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.293313] smsc95xx 2-1.5.1:1.0 eth1: unregister 'smsc95xx' usb-0000:00:1d.0-1.5.1, smsc95xx USB 2.0 Ethernet > [39203.293333] smsc95xx 2-1.5.1:1.0 eth1: hardware isn't capable of remote wakeup > [39203.322991] usb 2-1.5.2: USB disconnect, device number 5 > [39203.323794] usb 2-1.5.3: USB disconnect, device number 6 > [39203.367370] usb 2-1.5.4: USB disconnect, device number 7 > > The device(s) then reattach... > > [39203.698501] usb 2-1.5: new high-speed USB device number 8 using ehci-pci > [39203.790708] usb 2-1.5: New USB device found, idVendor=0424, idProduct=9514 > [39203.790718] usb 2-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > [39203.791226] hub 2-1.5:1.0: USB hub found > [39203.791387] hub 2-1.5:1.0: 5 ports detected > > I don't really know what happens first. > 'input0' and 'input1' are both the USB keyboard. > It would be nice to know why the reset was requested, and why the disconnects were done. > Is the recovery from the failed resets forcing the disconnects - or is that just a symptom > of the same underlying error? The resets were done because of communication errors. The errors occurred because the HID device's parent hub disconnected from the bus. I suppose the usbhid driver could stop working so hard, and simply give up when a reset fails instead of retrying the reset. That would reduce the number of error messages in the system log, but it wouldn't solve anything. > Trouble is this happens about once a day, and we haven't found anything that really > changes the frequency. It doesn't seem to be affected by real USB data (saturating > the ethernet interface makes little difference). > It might be that there are actually a lot of silent retries going on, but I don't > really know where to look to find out. > We currently have cut the 5v line on the USB interface - just in case it was carrying noise. > > Any ideas? Have you used a bus analyzer on the wire connected to the parent hub's upstream port? If you do, you should be able to see the events leading up to a reset. My guess is that they will all look normal until at some point the HID device stops responding to packets. Probably the hub disconnects from the bus first and that's the reason the responses stop. Why does the hub disconnect? I have no idea. Alan Stern -- 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
