Re: linux-next crash in xhci_add_ep_to_interval

[Valdis . Kletnieks]

On Thu, 05 Jun 2014 08:55:07 -0700, Dan Williams said:

> > On a working boot, it progresses:
>
> Is a working boot after reverting that change, or it intermittently
> works?  If it's the latter I'm not sure I trust the bisect result,
> yet.

Oh, it's a 100% guaranteed crash.  The following is from a good kernel:

> > [    3.823139] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020
> > [    3.823160] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > [    3.823174] usb 3-4.1: Product: PS2toUSB Adapter
> > [    3.823187] usb 3-4.1: Manufacturer: GASIA
> > [    3.842836] input: GASIA PS2toUSB Adapter as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.0/0003:0E8F:0020.0001/input/input14
> > [    3.848598] hid-generic 0003:0E8F:0020.0001: input,hidraw0: USB HID v1.10 Keyboard [GASIA PS2toUSB Adapter] on usb-0000:00:14.0-4.1/input0
> > [    3.863592] input: GASIA PS2toUSB Adapter as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4.1/3-4.1:1.1/0003:0E8F:0020.0002/input/input15
> > [    3.878608] hid-generic 0003:0E8F:0020.0002: input,hidraw1: USB HID v1.10 Mouse [GASIA PS2toUSB Adapter] on usb-0000:00:14.0-4.1/input1

I'm booted on next-20140519


> It's a really odd place to crash relative to the peer port changes
> since those do not affect any xhci internals.  At first glance this
> also does not look related to the command queue changes.  Mathias, any
> ideas?
>
> Valdis, can you get me the output of:
>
> $ gdb drivers/usb/host/xhci-hcd.ko
> (gdb) li *(xhci_add_ep_to_interval_table+0xc8)

(gdb) li *(xhci_add_ep_to_interval_table+0xc8)
0x10c9 is in xhci_add_ep_to_interval_table (drivers/usb/host/xhci.c:2446).
2441                    normalized_interval = ep_bw->ep_interval - 3;
2442
2443            if (normalized_interval == 0)
2444                    bw_table->interval0_esit_payload += ep_bw->max_esit_payload;
2445            interval_bw = &bw_table->interval_bw[normalized_interval];
2446            interval_bw->num_packets += ep_bw->num_packets;
2447            switch (udev->speed) {
2448            case USB_SPEED_LOW:
2449                    interval_bw->overhead[LS_OVERHEAD_TYPE] += 1;
2450                    break;

Note that's as of the end of the git bisect.  Looks like it picked up
a duff value for interval_bw somehow, but I have no idea why.

Yeah, you're right, the bisected commit doesn't seem to have anything
to do with it.  Weird. ;)

Attachment: pgp_CVbnjDeLq.pgp
Description: PGP signature