On Mon, 8 Apr 2019, Bollinger, Seth wrote: > On Apr 8, 2019, at 9:33 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx<mailto:stern@xxxxxxxxxxxxxxxxxxx>> wrote: > > In theory, the device should report a block size of 1024. Does it > actually do this? A usbmon trace (on the host) showing what happens > when the device is first plugged in will provide the answer. Can you > collect one and post it? > > Here it is: And here's the important part: > ffff8000722380c0 209057099 S Bo:2:006:2 -115 31 = 55534243 03000000 08000000 80000a25 00000000 00000000 00000000 000000 > ffff8000722380c0 209057109 C Bo:2:006:2 0 31 > > ffff800073cf8f00 209057115 S Bi:2:006:1 -115 8 < > ffff800073cf8f00 209057185 C Bi:2:006:1 0 8 = 0e69ffff 00000200 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. 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. Alan Stern
