On Tue, 9 Apr 2019, Ming Lei wrote: > On Tue, Apr 9, 2019 at 11:20 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 9 Apr 2019, Bollinger, Seth wrote: > > > > > > 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. > > > > > > Ok, I have it this time. I must have sniffed the wrong bus last time. > > > > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: bulk A 000004bf ty 03 st 00000000 T 3584 L 0 ch 00000081 ep 1 fl 0 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: bulk A 000004bf ty 03 st 00000000 T 4096 L 0 ch 00000081 ep 1 fl 0 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: message repeated 2 times: [ bulk A 000004bf ty 03 st 00000000 T 4096 L 0 ch 00000081 ep 1 fl 0] > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: BI completion: st 0 stat -75 AL 0 ec 0 returning -75 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: bulk A 000004bf ty 03 st 00000000 T 4096 L 0 ch 00000081 ep 1 fl 0 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: message repeated 3 times: [ bulk A 000004bf ty 03 st 00000000 T 4096 L 0 ch 00000081 ep 1 fl 0] > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: BI completion: st 0 stat -2 AL 0 ec 0 returning -2 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: message repeated 6 times: [ BI completion: st 0 stat -2 AL 0 ec 0 returning -2] > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: bulk A 000004bf ty 03 st 00000000 T 13 L 0 ch 00000081 ep 0 fl 4271644 > > > 2019-04-09 13:09:32 AW24-D00005 user.notice awusbd[2514]: BI completion: st 0 stat -71 AL 0 ec 0 returning -71 > > > > All right, now I see the problem. It's here: > > > > > ffff800074057b40 1058554625 S Bo:2:098:2 -115 31 = 55534243 07010000 007e0000 80000a28 000001ff c100003f 00000000 000000 > > > ffff800074057b40 1058554638 C Bo:2:098:2 0 31 > > > > ffff800074057cc0 1058555039 S Bi:2:098:1 -115 3584 < > > > ffff800074057cc0 1058555066 C Bi:2:098:1 -75 3584 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > ffff800073e0fb40 1058555113 S Bi:2:098:1 -115 4096 < > > > ffff8000723f5f00 1058555129 S Bi:2:098:1 -115 4096 < > > > ffff8000723f5c00 1058555148 S Bi:2:098:1 -115 4096 < > > > ffff8000723f5b40 1058555202 S Bi:2:098:1 -115 4096 < > > > ffff8000723f5a80 1058555224 S Bi:2:098:1 -115 4096 < > > > ffff8000711d8780 1058555237 S Bi:2:098:1 -115 4096 < > > > ffff800074091900 1058555255 S Bi:2:098:1 -115 4096 < > > > ffff800073e0fb40 1058555769 C Bi:2:098:1 -2 4096 = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > > This is a READ command asking for 63 blocks (31.5 KB) of data. The > > device sends 7 4096-byte packets followed by a 3584-byte packet, but > > the kernel's scatter-gather list contains a 3584-byte buffer followed > > by 7 4096-byte buffers. Since the VHCI driver doesn't have full native > > SG support, it needs each packet to be stored in a contiguous region of > > memory. In this case the first packet causes an overrun error. > > > > The best way to fix the problem would be to improve the SG support in > > VHCI. Short of that, we would like to tell the block layer that this > > device requires all scatterlist elements (except the last one) for any > > single command to be multiples of 1024 bytes, in spite of the fact that > > the device claims to have a block size of 512 bytes. > > You may try the following limit: > > blk_queue_virt_boundary(q, 1024 - 1); Okay. Is there any documentation explaining exactly what virt_boundary_mask, dma_alignment, and other related block queue parameters really mean? Seth, you can try adding: blk_queue_virt_boundary(sdev->request_queue, 1024 - 1); in drivers/usb/storage/scsiglue.c:slave_alloc(), just after the call to blk_queue_update_dma_alignment(). Perhaps that will help. Alan Stern
