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:
pgp5fTJOUCwW_.pgp
Description: PGP signature
