On Mon, 8 Apr 2019, Bollinger, Seth wrote: > On Apr 8, 2019, at 12:23 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx<mailto:stern@xxxxxxxxxxxxxxxxxxx>> wrote: > > The two big-endian numbers at the end of this line are the logical > block address of the device's last block and the logical block size in > bytes. Thus the device claims to have 512-byte blocks. > > I suspect you have run across a bug in the device. It shouldn't mind > that it was asked to send 3584 bytes of data; it ought to send 3 > 1024-byte packets followed by a short 512-byte packet. Instead it > seems to be sending 4 1024-byte packets, thus causing an error. At > least, that's my guess. > > I am confused as to how this could be a device bug. They have worked in every machine we’ve used them in so far, save for the USBIP use case. I’ve spent quite some time trying to reproduce in physical machines, even the same one that experiences the problem using USBIP. I don't know. That's just my best guess based on the data seen so far. > To help verify this, can you send a similar usbmon trace on the server > showing what happens when the EOVERFLOW error occurs? The debug > messages in your April 6 email don't contain all the detailed > information. > > I believe this trace should have captured the failure, although I’m not seeing the odd read here... No, that trace did not show any failure. Did you see the corresponding error messages in the kernel log while you were collecting the trace? Maybe you can try again. Alan PS: Why doesn't your email client insert some sort of "reply indent" string, such as "> "? Looking at the messages you send, it's not so easy to tell which parts were written by you and which you are replying to.
