On Tue, Mar 4, 2014 at 5:47 AM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > 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? Sorry, could you explain why you want to revert commit 3804fad45411 (USBNET: ax88179_178a)? If xHCI won't plan to support arbitrary-length scatter-gather any more, that is fine to revert the commit forever. Otherwise, it should be better to just clear no_sg_constraint in xhcd, shouldn't it? Thanks, -- Ming Lei -- 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
