Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
[Adding Mathias.] On Thu, Mar 06, 2014 at 12:27:59AM -0600, Robert Hancock wrote: > On 05/03/14 11:17 PM, Robert Hancock wrote: > >I have a USB 3.0 multi-card reader device: > > > >Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. > > > >which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 > >specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). > >Below is what I get in dmesg. Essentially there's a bunch of > >input/output errors making the reader mostly unusable. > > > >This is on an Intel Haswell machine with this controller: > > > >00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series > >Chipset Family USB xHCI [8086:8c31] (rev 05) > > > >It looks like there were some XHCI commits that went into 3.13.5 so it > >seems likely one of those is the cause. I can try current git if there's > >anything in there that's likely to fix it. But it does seem like a > >regression got into the stable kernel in this respect. > > Bisecting between 3.13.4 and 3.13.5 gives me this: > > c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit > commit c8f44f98901994832ccecb87c3dd7900274b699a > Author: Sarah Sharp > Date: Fri Jan 31 11:26:25 2014 -0800 > > xhci 1.0: Limit arbitrarily-aligned scatter gather. Yes, this is a known regression. That commit should be reverted in 3.14-rc shortly, and the patch will be backported to stable kernels. Mathias is taking over as xHCI maintainer, and he will queue the revert patches to Greg shortly. Sarah Sharp > > commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. > > xHCI 1.0 hosts have a set of requirements on how to align transfer > buffers on the endpoint rings called "TD fragment" rules. When the > ax88179_178a driver added support for scatter gather in 3.12, with > commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: > enable tso if usb host supports sg dma", it broke the device under xHCI > 1.0 hosts. Under certain network loads, the device would see an > unexpected short packet from the host, which would cause the device to > stop sending ethernet packets, even through USB packets would still be > sent. > > Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB > payload burst" attempted to fix this. It was a quick hack to partially > implement the TD fragment rules. However, it caused regressions in the > usb-storage layer and userspace USB drivers using libusb. The patches > to attempt to fix this are too far reaching into the USB core, and we > really need to implement the TD fragment rules correctly in the xHCI > driver, instead of continuing to wallpaper over the issues. > > Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 > hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, > so don't set it for 1.0 hosts. This should not impact usb-storage or > usbfs behavior, since they pass down max packet sized aligned sg-list > entries (512 for USB 2.0 and 1024 for USB 3.0). > > Signed-off-by: Sarah Sharp > Tested-by: Mark Lord > Cc: David Laight > Cc: Bjørn Mork > Cc: Freddy Xin > Cc: Ming Lei > Signed-off-by: Greg Kroah-Hartman > > > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
[Adding Mathias.] On Thu, Mar 06, 2014 at 12:27:59AM -0600, Robert Hancock wrote: On 05/03/14 11:17 PM, Robert Hancock wrote: I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. Bisecting between 3.13.4 and 3.13.5 gives me this: c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit commit c8f44f98901994832ccecb87c3dd7900274b699a Author: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Fri Jan 31 11:26:25 2014 -0800 xhci 1.0: Limit arbitrarily-aligned scatter gather. Yes, this is a known regression. That commit should be reverted in 3.14-rc shortly, and the patch will be backported to stable kernels. Mathias is taking over as xHCI maintainer, and he will queue the revert patches to Greg shortly. Sarah Sharp commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called TD fragment rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 USBNET: ax88179_178a: enable tso if usb host supports sg dma, it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Tested-by: Mark Lord ml...@pobox.com Cc: David Laight david.lai...@aculab.com Cc: Bjørn Mork bj...@mork.no Cc: Freddy Xin fre...@asix.com.tw Cc: Ming Lei ming@canonical.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
On 05/03/14 11:17 PM, Robert Hancock wrote: I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. Bisecting between 3.13.4 and 3.13.5 gives me this: c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit commit c8f44f98901994832ccecb87c3dd7900274b699a Author: Sarah Sharp Date: Fri Jan 31 11:26:25 2014 -0800 xhci 1.0: Limit arbitrarily-aligned scatter gather. commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called "TD fragment" rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a: enable tso if usb host supports sg dma", it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp Tested-by: Mark Lord Cc: David Laight Cc: Bjørn Mork Cc: Freddy Xin Cc: Ming Lei Signed-off-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xHCI regression in stable 3.13.5 with USB3 card reader
I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. [ 25.177926] usb 4-2: Disable of device-initiated U1 failed. [ 26.906531] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 26.918439] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 26.918441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 26.921116] sd 6:0:0:0: [sdc] Unhandled error code [ 26.921118] sd 6:0:0:0: [sdc] [ 26.921120] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 26.921120] sd 6:0:0:0: [sdc] CDB: [ 26.921121] Read(10): 28 00 00 00 08 23 00 00 f0 00 [ 26.921126] end_request: I/O error, dev sdc, sector 2083 [ 27.208871] sd 6:0:0:0: [sdc] Media Changed [ 27.208874] sd 6:0:0:0: [sdc] [ 27.208875] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 27.208876] sd 6:0:0:0: [sdc] [ 27.208877] Sense Key : Unit Attention [current] [ 27.208878] sd 6:0:0:0: [sdc] [ 27.208880] Add. Sense: Not ready to ready change, medium may have changed [ 27.208880] sd 6:0:0:0: [sdc] CDB: [ 27.208881] Read(10): 28 00 00 00 08 24 00 00 ef 00 [ 27.208886] end_request: I/O error, dev sdc, sector 2084 [ 27.210467] FAT-fs (sdc1): FAT read failed (blocknr 35) [ 49.420334] usb 4-2: Disable of device-initiated U1 failed. [ 51.139080] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 51.150979] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 51.150981] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 51.153663] sd 6:0:0:0: [sdc] Unhandled error code [ 51.153665] sd 6:0:0:0: [sdc] [ 51.153666] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 51.153667] sd 6:0:0:0: [sdc] CDB: [ 51.153668] Read(10): 28 00 00 00 08 25 00 00 ee 00 [ 51.153672] end_request: I/O error, dev sdc, sector 2085 [ 51.441377] sd 6:0:0:0: [sdc] Media Changed [ 51.441379] sd 6:0:0:0: [sdc] [ 51.441380] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 51.441381] sd 6:0:0:0: [sdc] [ 51.441382] Sense Key : Unit Attention [current] [ 51.441384] sd 6:0:0:0: [sdc] [ 51.441385] Add. Sense: Not ready to ready change, medium may have changed [ 51.441386] sd 6:0:0:0: [sdc] CDB: [ 51.441386] Read(10): 28 00 00 00 08 26 00 00 ed 00 [ 51.441391] end_request: I/O error, dev sdc, sector 2086 [ 51.441454] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442083] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442570] FAT-fs (sdc1): FAT read failed (blocknr 235) [ 164.219227] usb 4-2: Disable of device-initiated U1 failed. [ 165.938731] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 165.950669] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 165.950672] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 165.953366] sd 6:0:0:0: [sdc] Unhandled error code [ 165.953368] sd 6:0:0:0: [sdc] [ 165.953369] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 165.953370] sd 6:0:0:0: [sdc] CDB: [ 165.953371] Read(10): 28 00 00 00 08 27 00 00 ec 00 [ 165.953375] end_request: I/O error, dev sdc, sector 2087 [ 166.240995] sd 6:0:0:0: [sdc] Media Changed [ 166.240997] sd 6:0:0:0: [sdc] [ 166.240999] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 166.241000] sd 6:0:0:0: [sdc] [ 166.241000] Sense Key : Unit Attention [current] [ 166.241002] sd 6:0:0:0: [sdc] [ 166.241003] Add. Sense: Not ready to ready change, medium may have changed [ 166.241004] sd 6:0:0:0: [sdc] CDB: [ 166.241005] Read(10): 28 00 00 00 08 28 00 00 eb 00 [ 166.241010] end_request: I/O error, dev sdc, sector 2088 [ 166.241055] FAT-fs (sdc1): FAT read failed (blocknr 39) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xHCI regression in stable 3.13.5 with USB3 card reader
I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. [ 25.177926] usb 4-2: Disable of device-initiated U1 failed. [ 26.906531] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 26.918439] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 26.918441] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 26.921116] sd 6:0:0:0: [sdc] Unhandled error code [ 26.921118] sd 6:0:0:0: [sdc] [ 26.921120] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 26.921120] sd 6:0:0:0: [sdc] CDB: [ 26.921121] Read(10): 28 00 00 00 08 23 00 00 f0 00 [ 26.921126] end_request: I/O error, dev sdc, sector 2083 [ 27.208871] sd 6:0:0:0: [sdc] Media Changed [ 27.208874] sd 6:0:0:0: [sdc] [ 27.208875] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 27.208876] sd 6:0:0:0: [sdc] [ 27.208877] Sense Key : Unit Attention [current] [ 27.208878] sd 6:0:0:0: [sdc] [ 27.208880] Add. Sense: Not ready to ready change, medium may have changed [ 27.208880] sd 6:0:0:0: [sdc] CDB: [ 27.208881] Read(10): 28 00 00 00 08 24 00 00 ef 00 [ 27.208886] end_request: I/O error, dev sdc, sector 2084 [ 27.210467] FAT-fs (sdc1): FAT read failed (blocknr 35) [ 49.420334] usb 4-2: Disable of device-initiated U1 failed. [ 51.139080] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 51.150979] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 51.150981] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 51.153663] sd 6:0:0:0: [sdc] Unhandled error code [ 51.153665] sd 6:0:0:0: [sdc] [ 51.153666] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 51.153667] sd 6:0:0:0: [sdc] CDB: [ 51.153668] Read(10): 28 00 00 00 08 25 00 00 ee 00 [ 51.153672] end_request: I/O error, dev sdc, sector 2085 [ 51.441377] sd 6:0:0:0: [sdc] Media Changed [ 51.441379] sd 6:0:0:0: [sdc] [ 51.441380] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 51.441381] sd 6:0:0:0: [sdc] [ 51.441382] Sense Key : Unit Attention [current] [ 51.441384] sd 6:0:0:0: [sdc] [ 51.441385] Add. Sense: Not ready to ready change, medium may have changed [ 51.441386] sd 6:0:0:0: [sdc] CDB: [ 51.441386] Read(10): 28 00 00 00 08 26 00 00 ed 00 [ 51.441391] end_request: I/O error, dev sdc, sector 2086 [ 51.441454] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442083] FAT-fs (sdc1): FAT read failed (blocknr 37) [ 51.442570] FAT-fs (sdc1): FAT read failed (blocknr 235) [ 164.219227] usb 4-2: Disable of device-initiated U1 failed. [ 165.938731] usb 4-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 165.950669] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a00 [ 165.950672] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88003f912a40 [ 165.953366] sd 6:0:0:0: [sdc] Unhandled error code [ 165.953368] sd 6:0:0:0: [sdc] [ 165.953369] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [ 165.953370] sd 6:0:0:0: [sdc] CDB: [ 165.953371] Read(10): 28 00 00 00 08 27 00 00 ec 00 [ 165.953375] end_request: I/O error, dev sdc, sector 2087 [ 166.240995] sd 6:0:0:0: [sdc] Media Changed [ 166.240997] sd 6:0:0:0: [sdc] [ 166.240999] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 166.241000] sd 6:0:0:0: [sdc] [ 166.241000] Sense Key : Unit Attention [current] [ 166.241002] sd 6:0:0:0: [sdc] [ 166.241003] Add. Sense: Not ready to ready change, medium may have changed [ 166.241004] sd 6:0:0:0: [sdc] CDB: [ 166.241005] Read(10): 28 00 00 00 08 28 00 00 eb 00 [ 166.241010] end_request: I/O error, dev sdc, sector 2088 [ 166.241055] FAT-fs (sdc1): FAT read failed (blocknr 39) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xHCI regression in stable 3.13.5 with USB3 card reader (Bisected)
On 05/03/14 11:17 PM, Robert Hancock wrote: I have a USB 3.0 multi-card reader device: Bus 004 Device 002: ID 05e3:0743 Genesys Logic, Inc. which seems to work fine in 3.13.4 (Fedora version kernel-3.13.4-200 specifically) but fails in 3.13.5 (specifically kernel-3.13.5-202). Below is what I get in dmesg. Essentially there's a bunch of input/output errors making the reader mostly unusable. This is on an Intel Haswell machine with this controller: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) It looks like there were some XHCI commits that went into 3.13.5 so it seems likely one of those is the cause. I can try current git if there's anything in there that's likely to fix it. But it does seem like a regression got into the stable kernel in this respect. Bisecting between 3.13.4 and 3.13.5 gives me this: c8f44f98901994832ccecb87c3dd7900274b699a is the first bad commit commit c8f44f98901994832ccecb87c3dd7900274b699a Author: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Fri Jan 31 11:26:25 2014 -0800 xhci 1.0: Limit arbitrarily-aligned scatter gather. commit 247bf557273dd775505fb9240d2d152f4f20d304 upstream. xHCI 1.0 hosts have a set of requirements on how to align transfer buffers on the endpoint rings called TD fragment rules. When the ax88179_178a driver added support for scatter gather in 3.12, with commit 804fad45411b48233b48003e33a78f290d227c8 USBNET: ax88179_178a: enable tso if usb host supports sg dma, it broke the device under xHCI 1.0 hosts. Under certain network loads, the device would see an unexpected short packet from the host, which would cause the device to stop sending ethernet packets, even through USB packets would still be sent. Commit 35773dac5f86 usb: xhci: Link TRB must not occur within a USB payload burst attempted to fix this. It was a quick hack to partially implement the TD fragment rules. However, it caused regressions in the usb-storage layer and userspace USB drivers using libusb. The patches to attempt to fix this are too far reaching into the USB core, and we really need to implement the TD fragment rules correctly in the xHCI driver, instead of continuing to wallpaper over the issues. Disable arbitrarily-aligned scatter-gather in the xHCI driver for 1.0 hosts. Only the ax88179_178a driver checks the no_sg_constraint flag, so don't set it for 1.0 hosts. This should not impact usb-storage or usbfs behavior, since they pass down max packet sized aligned sg-list entries (512 for USB 2.0 and 1024 for USB 3.0). Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Tested-by: Mark Lord ml...@pobox.com Cc: David Laight david.lai...@aculab.com Cc: Bjørn Mork bj...@mork.no Cc: Freddy Xin fre...@asix.com.tw Cc: Ming Lei ming@canonical.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
