> From: Eric Dumazet [mailto:eric.dumazet@xxxxxxxxx] > On Tue, 2013-11-19 at 14:43 +0000, David Laight wrote: > > > It isn't directly a TSO problem. > > There has always been a bug in the xhci driver for fragmented buffers. > > TSO just means it is given a lot of fragmented buffers. > > > > As well as user-supplied fragmented buffers, the bug affects > > internal fragmentation that happens whenever a buffer crosses a 64k > > byte boundary (please hw engineers - stop doing this!) > > TCP stack uses order-3 allocations. > > This means 32KB for x86 (PAGE_SIZE=4096) > > What is PAGE_SIZE for your arches ? > > If there is a 6KB limit, we might adapt TCP to make sure we do not cross > a 64KB boundary. > > Other strategy would be to detect this case in the driver and split a > problematic segment into two parts. The xhci code does all the checks for buffer fragments crossing 64k boundaries. I've posted a patch that uses a conservative upper limit for the number of fragments: 2 * number_of_sg_buffs + xfer_len/65536. This saves scanning the sg list twice. For those not reading linux-usb: The xhci 'bug' is that an SG list may only cross the end of a ring segment at an aligned length. For USB2 devices this will be 512 bytes. For USB3 the documented alignment could be 16k (depends on a burst size), but might only be 1k. (This is another place where the hw engineers haven't made life easy.) The only simple solution is to ensure that a SG list doesn't cross the end of a ring segment. David ��.n��������+%������w��{.n�����������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f