On Fri, 28 Feb 2014, Sarah Sharp wrote:
> When testing 3.14-rc1 with a USB 3.0 Lexar flash drive, the drive fails
> to be mounted. I added a bit of debugging to the USB core:
>
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 9ff665f1322f..eff59ac37865 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -430,9 +430,16 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> struct scatterlist *sg;
> int i;
>
> - for_each_sg(urb->sg, sg, urb->num_sgs - 1, i)
> - if (sg->length % max)
> + for_each_sg(urb->sg, sg, urb->num_sgs - 1, i) {
> + if (sg->length % max) {
> + dev_dbg(&dev->dev,
> + "URB sg entry %d of %d, size %d not a multiple of ep%d%s max packet %d\n",
> + i, urb->num_sgs, sg->length,
> + usb_endpoint_num(&ep->desc),
> + is_out ? "out" : "in", max);
> return -EINVAL;
> + }
> + }
> }
>
> That revealed the SCSI request fails because the USB core is rejecting a
> scatter-gather list with an entry that isn't aligned to the max packet size:
> Feb 28 09:45:30 xanatos kernel: [ 376.449316] usb 2-2: URB sg entry 0 of 17, size 1536 not a multiple of ep1in max packet 1024
Notice the request length: 1536. That's three 512-byte sectors. A
little unusual, since most I/O is done in units of pages, which are
4096 bytes.
> It's failing because of commit 247bf557273d "xhci 1.0: Limit
> arbitrarily-aligned scatter gather." That commit clears the
> hcd->self.no_sg_constraint flag if the host is a 1.0 host (which my
> Panther Point host is). It was put in to avoid TD fragment issues on
> 1.0 hosts with ethernet devices. (Note, this also means that David
> Laight's potential work-around patch [1] wouldn't help if
> arbitrary-length scatter gather bigger than a ring segment was
> submitted.)
>
> The behavior for reproducing this is odd. I can only reproduce this on
> my Ubuntu 13.10 laptop with Intel Panther Point xHCI, when the device is
> running at SuperSpeed. If I plug the device into an EHCI port, or
> behind a USB 2.0 hub plugged into an xHCI port, I never see these
> arbitrary-length scatter-gather list entries. Dan can't reproduce this
> on his Intel Haswell machine running Fedora at all.
Some of this behavior is to be expected. 1536 isn't a multiple of 1024
(the maxpacket size when running at SuperSpeed), but it _is_ a multiple
of 512 (the maxpacket size when running at high speed). Therefore the
failure won't occur when the drive is attached to an EHCI controller or
is behind a USB-2 hub.
> The only speed-based decision I see usb-storage making is whether to
> clear the US_FLOW_GO_SLOW flag. Changing that to set the flag for
> SuperSpeed devices as well didn't help:
That has nothing to do with this. The GO_SLOW flag tells usb-storage
to add a delay between the command phase and the data phase; it doesn't
affect the sizes of the transfers.
> I'm stumped as to why we get arbitrary-length scatter-gather for
> SuperSpeed devices only,
You don't. The same transfers occur at high speed -- it's just that
they don't cause an error.
> and only under Ubuntu. Perhaps this comes
> directly from userspace?
Maybe. I doubt the kernel would issue such a request on its own. A
usbmon trace might shed a little light, although it won't tell what
program (if any) issued the request.
Does the same thing happen if you prevent the system from automatically
trying to mount the volume?
> If we can't figure out how to get max-packet sized scatter-gather list
> entries from the mass storage driver, Mathias is going to need to:
The SG entries don't come from usb-storage; they come from the block
layer. As far as I know, there is no way to tell the block layer that
each element in an SG list (except the last) must be a multiple of
some specific size.
> revert commit 3804fad45411 USBNET: ax88179_178a: enable tso if usb host supports sg dma
> revert commit 247bf557273d xhci 1.0: Limit arbitrarily-aligned scatter gather.
>
> And we'll need to focus on getting the TD fragments supported in 3.16.
So far we've gotten away with this at high speed or below, because no
USB mass-storage devices have a block size smaller than 512 (at least,
none that I've ever heard of). But when the maxpacket size is 1024, a
request for an odd number of blocks can cause trouble.
Alan Stern
--
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
