On Sat, 6 Apr 2019, Bollinger, Seth wrote: > On Apr 6, 2019, at 10:34 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx<mailto:stern@xxxxxxxxxxxxxxxxxxx>> wrote: > > Why does a 3-KB read cause a failure? It should work perfectly well. > > I thought because the scsi command asked to read 32K. > > If I’m incorrect in my assumption, and the chunked read should work, do you have any theories? I enabled debug spew on xhci, but nothing presented itself more than the EOVERFLOW being set when it detects babble. I would appreciate any debug guidance you might be able to offer. :) > > [ 179.330047] usb 2-1.3: usbdev_do_ioctl: SUBMITURB > [ 179.334761] usb 2-1.3: userurb 0000ffff70001640, ep1 bulk-in, length 3584 > [ 179.341565] usb 2-1.3: usbdev_do_ioctl: SUBMITURB > [ 179.341569] xhci_hcd 0001:01:00.0: Babble error for slot 8 ep 2 on endpoint > [ 179.341574] xhci_hcd 0001:01:00.0: // Ding dong! > [ 179.341578] xhci_hcd 0001:01:00.0: Giveback URB ffff800073b48a80, len = 3584, expected = 3584, status = -75 > [ 179.341581] usb 2-1.3: urb complete Can you provide the "lsusb -v" output for the storage device as shown on both computers? I want to see if the server and the client disagree on the maxpacket sizes for the bulk endpoints. The key is that 3584 is a multiple of 512 but not of 1024. Alan Stern
