On Tue, Apr 13, 2010 at 03:25:43PM -0400, Alan Stern wrote: > On Tue, 13 Apr 2010, Sarah Sharp wrote: > > > Ok, I think I understand what happened. The xhci-streams branch you > > were testing against was based against 2.6.32 (the original one that > > came out, not any of the stable versions that followed). That kernel > > didn't have David Vrabel's patch to make the URB scatter gather support > > more generic (commit 4c1bd3d7a7d114dabd58f62f386ac4bfd268be1f), and thus > > the USB mass storage driver didn't check bus->sg_tablesize. > > > > When you modified max_sectors, the mass storage driver would blindly > > enqueue a scatter gather list with more entries than the xHCI driver > > could handle. We never saw this issue before because the max_sectors > > was always low. You didn't see this issue on the xhci-large-tx branch > > because it's based on 2.6.34-rc2. > > > > I don't think we need to patch the stable kernel series, because it > > won't have a driver that triggers this bug, and we won't allow new > > drivers to go into the stable kernels. > > If I understand this correctly, it means that you don't have to worry > about enlarging the rings on-the-fly. The number of outstanding > scatterlist elements will always be limited by TRBS_PER_SEGEMENT. > > Is that correct? Yes, the number of sglist entries will always be limited by TRBS_PER_SEGMENT with the current code. It means I don't need to add code to dynamically expand the rings, unless I want to handle large sglists. There might be some performance issues with transferring smaller sglists, but it's definitely not at bug priority. I'll probably focus on other things, unless someone has a real need for this. Ramya, why did you want to see very large scatter gather lists? Was there a performance issue? Sarah Sharp -- 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
