Bug#733826: crazy loop "xhci_hcd Too many fragments"
> From: Alan Stern
> Subject: Re: Bug#733826: crazy loop "xhci_hcd Too many fragments"
>
> On Mon, 6 Jan 2014, Ben Hutchings wrote:
>
> > On Sat, 2014-01-04 at 05:44 +0800, jidanni@jidanni.org wrote:
...
> > > # cat /var/log/syslog
> > >
> > > Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123
> > > Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123
> > > Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed
> > > Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates
> > > Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd 0000:00:14.0: Too many fragments 79, max
> 63
> > > Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd 0000:00:14.0: Too many fragments 79, max
> 63
> > > Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max
> 63
> > >
> > > 100000 lines later... oops I mean an actual MILLION lines later
> >
> > Assuming my fix for the repetition is correct, the remaining problem is
> > why usb-storage is generating such large/fragmented urbs.
>
> usb-storage doesn't generate large or fragmented anything. It merely
> passes on the scatter-gather information it gets from the block layer.
Although not a real fix to the underlying problem, it seems that the default
ring size is far too small.
Any amount of network traffic also activates the ring expansion code.
IIRC each ring entry is 16 bytes, so increasing the ring size to 256
still keeps the rings to a single 4k page.
Whether anything regularly exceeds 255 fragments is a another matter.
David
Reply to: