On Fri, 17 Nov 2017, Jérôme Carretero wrote: > > Here's the error: > > > > b5251480 0.505661 S Bo:6:008:2 -115 196608 = 540a2813 1a33dd99 > > ab76840c bf72fc6b 60f9fcaf 4d61822c c007ff4e ab72d022 b5251480 > > 0.506280 C Bo:6:008:2 -71 86016 > > > Out of curiosity, which tool produced this condensed output? I wrote a program for myself to translate pcap files into usbmon's text format. I find that format a lot easier to read than trying to deal with wireshark's "one packet at a time" approach. > > This means the kernel tried to write 196608 bytes to the drive. After > > 86016 had been transferred, the drive did not reply correctly to the > > next output transaction, causing the kernel to perform a reset. > > That's what happened, according to the viewpoint of the xhci-hcd > > driver. > > > > In theory it's possible that the drive did respond correctly and the > > information get messed up on the USB cable or on the computer's end. > > Wow, that sucks. > I had a mental image where the transactions used FEC and it would be > obviously possible to differentiate between cable/hub/endpoint errors. I don't see how FEC could help in a situation where a device sends a properly formatted message and then some component closer to the kernel improperly rejects it. 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
