On Thu, Jun 5, 2014 at 9:24 AM, <Valdis.Kletnieks@xxxxxx> wrote:
> 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. ;)
Actually, on second look I bet xhci_alloc_tt_info() is being called
while hdev->maxchild is not set. Let me throw together a debug
patch...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
