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);
Thanks,
Ming Lei
