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. > > > 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.
Ah, that makes sense now. > Does the same thing happen if you prevent the system from automatically > trying to mount the volume? If the system doesn't automatically mount the volume, the error doesn't occur. > > 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? Sarah Sharp -- 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
