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?
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?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
