From: Sarah Sharp
...
> The block layer may submit scatter-gather lists with entries that
> are multiples of 512-byte blocks. That's fine for USB 2.0 devices,
> where the bulk endpoint max packet size is 512 bytes. But USB 3.0
> devices have bulk endpoints with a 1024 byte max packet size.
>
> That means when the block layer submits a scatter-gather list with one
> entry that includes, say, three 512-byte blocks, this code will reject
> the URB if it's submitted to a USB 3.0 bulk endpoint:
>
> int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> {
> ...
> max = usb_endpoint_maxp(&ep->desc);
> ...
> } else if (urb->num_sgs && !urb->dev->bus->no_sg_constraint &&
> dev->speed != USB_SPEED_WIRELESS) {
> struct scatterlist *sg;
> int i;
>
> for_each_sg(urb->sg, sg, urb->num_sgs - 1, i)
> if (sg->length % max)
> return -EINVAL;
> }
>
> This results in failures with USB 3.0 drives. For me, a failure to
> auto-mount the device. For others, a read or write SCSI command
> failure. We can't introduce a regression in USB 3.0 mass storage in
> order to get better performance on one USB ethernet adapter.
>
> Until we get TD fragments implemented, we need to revert the commit
> 3804fad45411 and commit 247bf557273d. That will mean USB 3.0 mass
> storage works again, and (unfortunately) the ASIX driver performance
> won't be as good until we implement TD fragments.
You need to find out what happens when a request that fails the above
test gets split by a LINK TRB on the Intel 1.0 controller.
If, for example, there is a 3 sector read transfer the target will send
a 1k USB data block followed by a 512 byte one.
I suspect that the xhci controller will read the first 512 bytes into the
first buffer, hit the LINK TRB, and then terminate the data TRB with some
kind of error. It might read the last 512 bytes into the second buffer,
or might skip to the TRB list and treat the last 512 bytes as a separate
bulk transfer.
A similar write transfer is likely to generate two bulk transfers, the
first of 512 bytes, the second of 1k. What the target makes of that is
anybodies guess.
Just disabling the test won't make it work.
All it does it make it fail less often.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
