On Tue, 4 Mar 2014, Sarah Sharp wrote: > > David is right; this problem can't be fixed simply by reverting > > patches. The real problem is that the block layer has handed the USB > > stack an SG list that xhci-hcd cannot handle at all, in its current > > form. > > We do not know if the driver not implementing TD fragment rules impacts > USB storage devices. I can certainly look into that today, with the > xHCI 1.0 hosts I have on hand (Ivy Bridge and Haswell-ULT). I can > experiment with shorting the ring segment so that almost every SCSI > transfer has a link TRB in the middle, and use a USB 3.0 analyzer to see > whether there are any short packets or abnormal traffic on the bus. Okay, that's certainly worth doing. It might be even easier to use testusb with gadget zero. Tests 5 and 6 exercise bulk SG, and you can set the length parameter to 512. > > There are only two reasonable ways to fix this: Add appropriate TRB > > fragment handling into xhci-hcd, or use bounce buffers for non-aligned > > requests. > > Or disable scatter-gather for xHCI 1.0 hosts all together. That won't help. In fact, it would cause all of these questionable transfers to fail, not just those that cross a ring segment boundary. Without SG support in the HCD, the scatter-gather library routine would end up creating a single URB for 1536 bytes. For READ, it would fail with an overflow error when the device sent two 1024-byte packets. For WRITE, goodness knows what the device would do with an unexpected short packet. > Alan, what do you suggest we do for the stable kernels in the meantime > before we have TD fragment rules in place? 3.12 and 3.13 already have > those two patches, and I keep getting failure reports. At the moment, I guess the best you can do is keep the SG support in xhci-hcd, set the no_sg_constraint flag, and live with an occasional failure when a link TRB occurs at an odd sector boundary. Also disable SG in the ax88179 network driver. In other words, revert those two commits. > From a user perspective, USB 3.0 mass storage devices used to work > before 3.14-rc1. Theoretically, the TD fragment rules could have caused > an occasional disk glitch. Now the devices *will* fail, instead of > theoretically failing. From a user perspective, this looks like a > regression; the USB device obviously fails on 3.14-rc1, and may > sometimes silently fail on prior kernels. > > So what would you have me do to fix stable kernels? Reverting them seems to be the only choice for now. 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
