From: Sarah Sharp
> Greg, Dave, Freddy, question about cross-subsystem reverts below:
>
> On Fri, Feb 28, 2014 at 04:15:12PM -0500, Alan Stern wrote:
> > 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:
> > > 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.
...
> > 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.
...
> > > 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.
>
> Ok, we can't have SuperSpeed mass storage devices broken, so it looks
> like we'll have to revert the last patch to add scatter-gather to the
> ASIX driver to avoid that breakage. That means Mathias is going to need
> to revert those two commits then, since he's taking over pushing xHCI
> driver bug fixes this kernel.
>
> Greg, Dave, Freddy, how do you want to handle reverting commit
> 3804fad45411? Should that come through Dave's networking tree or Greg's
> USB tree?
I'm not sure what those two commits have to do with this problem.
In order to support a request with a non-terminal buffer that isn't
a multiple of 1k you need something to stop a LINK TRB being in the
middle of the transfer.
Otherwise the 1536 byte transfer (expected as a 1k block followed by
512byte one) can probably get sent as a 512byte block (terminating the
bulk data request) followed by a spurious 1k block. These should
generate horrid errors from the target disk.
The only code I've seen anyone suggest that will correctly send
these requests starts from the patches I've sent.
I suspect you need to apply ALL of the patches I've sent, and then
fixup the remaining problems.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
