> > 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. > We are checking a similar problem, in our case, change another hub can fix problem, add bus analyzer between hub and devices can decrease the failure rate. You can have some usb devices (eg, usb-serial) at usb-hub, and write some application to increase usb bus loading, and try to speed up the reproduce. Peter -- 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
