Bug#733826: crazy loop "xhci_hcd Too many fragments"
On Mon, Jan 06, 2014 at 10:06:33AM -0500, Alan Stern wrote:
> On Mon, 6 Jan 2014, Ben Hutchings wrote:
>
> > On Sat, 2014-01-04 at 05:44 +0800, jidanni@jidanni.org wrote:
> > > >>>>> "BH" == Ben Hutchings <ben@decadent.org.uk> writes:
> > > BH> And what were those error messages?
> > > BH> Which USB devices are you using (this is probably disk or network
> > > BH> related)?
> > >
> > > I had done an aptitude update on writing onto
> > > # fdisk -l
> > > Disk /dev/sdg: 3867 MB, 3867148288 bytes
> >
> > OK, the important thing is it's usb-storage.
> >
> > > 181 heads, 32 sectors/track, 1304 cylinders, total 7553024 sectors
> > > Units = sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 512 bytes
> > > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > > Disk identifier: 0xc3072e18
> > >
> > > # mount
> > > Device Boot Start End Blocks Id System
> > > /dev/sdg1 32 868799 434384 83 Linux
> > > /dev/sdg2 868800 7553023 3342112 83 Linux
> > >
> > > /dev/sdg2 on /var/cache/apt/archives type ext3 (rw,noatime,errors=remount-ro,data=ordered)
> > > /dev/sdg1 on /var/lib/apt/lists type ext3 (rw,noatime,errors=remount-ro,data=ordered)
> > >
> > > # 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.
And the block layer depends on drivers to tell it what their
scatter-gather capabilities are.
The answer appears to be that xhci is lying:
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
{
[...]
/* Accept arbitrarily long scatter-gather lists */
hcd->self.sg_tablesize = ~0;
and this value gets copied up the stack to the block layer.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
Reply to: