mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* linux-next crash in xhci_add_ep_to_interval
@ 2014-06-05 15:22 Valdis Kletnieks
  2014-06-05 15:55 ` Dan Williams
  0 siblings, 1 reply; 8+ messages in thread
From: Valdis Kletnieks @ 2014-06-05 15:22 UTC (permalink / raw)
  To: Dan Williams, Alan Stern; +Cc: linux-kernel, linux-usb, Greg Kroah-Hartman

[-- Attachment #1: Type: text/plain, Size: 7805 bytes --]

Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval
when it's docked in a newer dock that has USB3.

It's very possible that the BIOS is buggy - it isn't like I haven't found
BIOS bugs in every single Dell laptop I've had. :)  But that shouldn't
make the kernel crash....

lsusb reports:

Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor
Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 413c:5534 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter
Bus 003 Device 002: ID 413c:2134 Dell Computer Corp.
Bus 003 Device 004: ID 045e:0023 Microsoft Corp. Trackball Optical
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Git bisect comes down to this:

commit d8521afe35862f4fbe3ccd6ca37897c0a304edf3
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue May 20 18:08:28 2014 -0700

    usb: assign default peer ports for root hubs

    Assume that the peer of a superspeed port is the port with the same id
    on the shared_hcd root hub.  This identification scheme is required of
    external hubs by the USB3 spec [1].  However, for root hubs, tier mismatch
    may be in effect [2].  Tier mismatch can only be enumerated via platform
    firmware.  For now, simply perform the nominal association.

Thanks to pstore, we have the explosion:

[    3.974159] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020
[    3.974173] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.974247] usb 3-4.1: Product: PS2toUSB Adapter
[    3.974259] usb 3-4.1: Manufacturer: GASIA
[    3.975475] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
[    3.975643] IP: [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
[    3.975795] PGD 0
[    3.975849] Oops: 0002 [#1] PREEMPT SMP
[    3.975954] Modules linked in:
[    3.976029] CPU: 0 PID: 37 Comm: khubd Not tainted 3.15.0-rc5-00299-g7e73be2 #234
[    3.976169] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013
[    3.976304] task: ffff880128e809d0 ti: ffff880128e84000 task.ti: ffff880128e84000
[    3.976441] RIP: 0010:[<ffffffff8139abd4>]  [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
[    3.976631] RSP: 0018:ffff880128e85608  EFLAGS: 00010006
[    3.976732] RAX: 0000000000000003 RBX: 0000000000000000 RCX: ffff8800c5861800
[    3.976863] RDX: 0000000000000001 RSI: 0000000000000078 RDI: 0000000000000005
[    3.976997] RBP: ffff880128e85640 R08: ffff8801288f2228 R09: 0000000000000000
[    3.977125] R10: ffff880128e85968 R11: 0000000000000004 R12: ffff8801288f22fc
[    3.977255] R13: ffff8800c5861800 R14: ffff88003f878000 R15: 0000000000000007
[    3.977353] FS:  0000000000000000(0000) GS:ffff88012dc00000(0000) knlGS:0000000000000000
[    3.977440] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.977503] CR2: 0000000000000080 CR3: 00000000c5eb4000 CR4: 00000000001407f0
[    3.977578] Stack:
[    3.977606]  ffff8801288f2228 0000000000000000 ffff8801288f2000 ffff8801288f22fc
[    3.977708]  ffff88003f878000 ffff8800c5d8b000 0000000000000003 ffff880128e85990
[    3.977808]  ffffffff8139c76d ffff880128e85700 ffff880128e85680 0000000100000007
[    3.977910] Call Trace:
[    3.977948]  [<ffffffff8139c76d>] xhci_reserve_bandwidth+0x158/0x534
[    3.978022]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
[    3.978086]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
[    3.978148]  [<ffffffff8107e313>] ? __lock_acquire+0x696/0xedf
[    3.978215]  [<ffffffff8112256b>] ? dma_pool_alloc+0x188/0x225
[    3.978281]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
[    3.980065]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
[    3.981976]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
[    3.984302]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
[    3.986919]  [<ffffffff8107e313>] ? __lock_acquire+0x696/0xedf
[    3.989317]  [<ffffffff8139cb84>] ? xhci_configure_endpoint+0x3b/0x4b0
[    3.991817]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
[    3.994396]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
[    3.996896]  [<ffffffff8107eebf>] ? lock_acquire+0xc1/0x14e
[    3.998795]  [<ffffffff8139cb84>] ? xhci_configure_endpoint+0x3b/0x4b0
[    4.000407]  [<ffffffff813a84b0>] ? xhci_dbg_trace+0x3f/0x47
[    4.002724]  [<ffffffff8139cc88>] xhci_configure_endpoint+0x13f/0x4b0
[    4.005076]  [<ffffffff8139d706>] xhci_check_bandwidth+0x11e/0x231
[    4.007457]  [<ffffffff813791ce>] usb_hcd_alloc_bandwidth+0x21d/0x2bd
[    4.009787]  [<ffffffff8137be1b>] usb_set_configuration+0x282/0x6f9
[    4.012008]  [<ffffffff81371927>] ? usb_hub_to_struct_hub+0x30/0x32
[    4.014085]  [<ffffffff813847ec>] generic_probe+0x40/0x72
[    4.015894]  [<ffffffff8137d7e9>] usb_probe_device+0x28/0x3b
[    4.017332]  [<ffffffff81302f4d>] driver_probe_device+0xda/0x202
[    4.019226]  [<ffffffff81303075>] ? driver_probe_device+0x202/0x202
[    4.021241]  [<ffffffff8130309a>] __device_attach+0x25/0x38
[    4.023357]  [<ffffffff81301636>] bus_for_each_drv+0x80/0x85
[    4.025480]  [<ffffffff81302e36>] device_attach+0x66/0x87
[    4.027587]  [<ffffffff81302456>] bus_probe_device+0x34/0xe1
[    4.029659]  [<ffffffff8130099f>] device_add+0x325/0x531
[    4.031661]  [<ffffffff813744ca>] usb_new_device+0x450/0x66a
[    4.033502]  [<ffffffff8107d9df>] ? trace_hardirqs_on+0xd/0xf
[    4.035347]  [<ffffffff81565f03>] ? __mutex_unlock_slowpath+0x19d/0x1af
[    4.037082]  [<ffffffff81374ff2>] hub_port_connect+0x4be/0x700
[    4.038873]  [<ffffffff8137586a>] hub_events+0x636/0x7ba
[    4.040210]  [<ffffffff81375a23>] hub_thread+0x35/0x16b
[    4.041518]  [<ffffffff81075c8c>] ? prepare_to_wait_exclusive+0x6c/0x6c
[    4.043361]  [<ffffffff813759ee>] ? hub_events+0x7ba/0x7ba
[    4.045170]  [<ffffffff81059cb3>] kthread+0xd6/0xde
[    4.046884]  [<ffffffff81059bdd>] ? __kthread_parkme+0x62/0x62
[    4.048760]  [<ffffffff8156e0fc>] ret_from_fork+0x7c/0xb0
[    4.050117]  [<ffffffff81059bdd>] ? __kthread_parkme+0x62/0x62
[    4.051467] Code: 00 e9 c2 00 00 00 83 f8 03 41 8b 04 24 74 03 83 e8 03 85 c0 75 07 41 8b 54 24 10 01 13 48 98 41 8b 54 24 08 48 6b f0 28 48 01 de <01> 56 08 41 83 7d 1c 05 77 27 41 8b 55 1c ff 24 d5 80 cb 68 81
[    4.057974] RIP  [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
[    4.059737]  RSP <ffff880128e85608>
[    4.061767] CR2: 0000000000000080
[    4.063775] ---[ end trace 581dd718db50beb0 ]---

On a working boot, it progresses:

[    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

So something about the PS2 adapter plugged into the dock gives it indigestion.

ANy ideas?

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 15:22 linux-next crash in xhci_add_ep_to_interval Valdis Kletnieks
@ 2014-06-05 15:55 ` Dan Williams
  2014-06-05 16:24   ` Valdis.Kletnieks
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Williams @ 2014-06-05 15:55 UTC (permalink / raw)
  To: Valdis Kletnieks
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

[ adding Mathias ]

On Thu, Jun 5, 2014 at 8:22 AM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> Dell Latitude E6530, BIOS A11, seeing a crash in xhci_add_ep_to_interval
> when it's docked in a newer dock that has USB3.
>
> It's very possible that the BIOS is buggy - it isn't like I haven't found
> BIOS bugs in every single Dell laptop I've had. :)  But that shouldn't
> make the kernel crash....
>
> lsusb reports:
>
> Bus 002 Device 004: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor
> Bus 002 Device 003: ID 413c:2513 Dell Computer Corp. internal USB Hub of E-Port Replicator
> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 002: ID 413c:5534 Dell Computer Corp.
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 003: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter
> Bus 003 Device 002: ID 413c:2134 Dell Computer Corp.
> Bus 003 Device 004: ID 045e:0023 Microsoft Corp. Trackball Optical
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> Git bisect comes down to this:
>
> commit d8521afe35862f4fbe3ccd6ca37897c0a304edf3
> Author: Dan Williams <dan.j.williams@intel.com>
> Date:   Tue May 20 18:08:28 2014 -0700
>
>     usb: assign default peer ports for root hubs
>
>     Assume that the peer of a superspeed port is the port with the same id
>     on the shared_hcd root hub.  This identification scheme is required of
>     external hubs by the USB3 spec [1].  However, for root hubs, tier mismatch
>     may be in effect [2].  Tier mismatch can only be enumerated via platform
>     firmware.  For now, simply perform the nominal association.
>
> Thanks to pstore, we have the explosion:
>
> [    3.974159] usb 3-4.1: New USB device found, idVendor=0e8f, idProduct=0020
> [    3.974173] usb 3-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [    3.974247] usb 3-4.1: Product: PS2toUSB Adapter
> [    3.974259] usb 3-4.1: Manufacturer: GASIA
> [    3.975475] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
> [    3.975643] IP: [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
> [    3.975795] PGD 0
> [    3.975849] Oops: 0002 [#1] PREEMPT SMP
> [    3.975954] Modules linked in:
> [    3.976029] CPU: 0 PID: 37 Comm: khubd Not tainted 3.15.0-rc5-00299-g7e73be2 #234
> [    3.976169] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013
> [    3.976304] task: ffff880128e809d0 ti: ffff880128e84000 task.ti: ffff880128e84000
> [    3.976441] RIP: 0010:[<ffffffff8139abd4>]  [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
> [    3.976631] RSP: 0018:ffff880128e85608  EFLAGS: 00010006
> [    3.976732] RAX: 0000000000000003 RBX: 0000000000000000 RCX: ffff8800c5861800
> [    3.976863] RDX: 0000000000000001 RSI: 0000000000000078 RDI: 0000000000000005
> [    3.976997] RBP: ffff880128e85640 R08: ffff8801288f2228 R09: 0000000000000000
> [    3.977125] R10: ffff880128e85968 R11: 0000000000000004 R12: ffff8801288f22fc
> [    3.977255] R13: ffff8800c5861800 R14: ffff88003f878000 R15: 0000000000000007
> [    3.977353] FS:  0000000000000000(0000) GS:ffff88012dc00000(0000) knlGS:0000000000000000
> [    3.977440] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    3.977503] CR2: 0000000000000080 CR3: 00000000c5eb4000 CR4: 00000000001407f0
> [    3.977578] Stack:
> [    3.977606]  ffff8801288f2228 0000000000000000 ffff8801288f2000 ffff8801288f22fc
> [    3.977708]  ffff88003f878000 ffff8800c5d8b000 0000000000000003 ffff880128e85990
> [    3.977808]  ffffffff8139c76d ffff880128e85700 ffff880128e85680 0000000100000007
> [    3.977910] Call Trace:
> [    3.977948]  [<ffffffff8139c76d>] xhci_reserve_bandwidth+0x158/0x534
> [    3.978022]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
> [    3.978086]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
> [    3.978148]  [<ffffffff8107e313>] ? __lock_acquire+0x696/0xedf
> [    3.978215]  [<ffffffff8112256b>] ? dma_pool_alloc+0x188/0x225
> [    3.978281]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
> [    3.980065]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
> [    3.981976]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
> [    3.984302]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
> [    3.986919]  [<ffffffff8107e313>] ? __lock_acquire+0x696/0xedf
> [    3.989317]  [<ffffffff8139cb84>] ? xhci_configure_endpoint+0x3b/0x4b0
> [    3.991817]  [<ffffffff8107d5da>] ? mark_lock+0x2a/0x203
> [    3.994396]  [<ffffffff8107d810>] ? mark_held_locks+0x5d/0x74
> [    3.996896]  [<ffffffff8107eebf>] ? lock_acquire+0xc1/0x14e
> [    3.998795]  [<ffffffff8139cb84>] ? xhci_configure_endpoint+0x3b/0x4b0
> [    4.000407]  [<ffffffff813a84b0>] ? xhci_dbg_trace+0x3f/0x47
> [    4.002724]  [<ffffffff8139cc88>] xhci_configure_endpoint+0x13f/0x4b0
> [    4.005076]  [<ffffffff8139d706>] xhci_check_bandwidth+0x11e/0x231
> [    4.007457]  [<ffffffff813791ce>] usb_hcd_alloc_bandwidth+0x21d/0x2bd
> [    4.009787]  [<ffffffff8137be1b>] usb_set_configuration+0x282/0x6f9
> [    4.012008]  [<ffffffff81371927>] ? usb_hub_to_struct_hub+0x30/0x32
> [    4.014085]  [<ffffffff813847ec>] generic_probe+0x40/0x72
> [    4.015894]  [<ffffffff8137d7e9>] usb_probe_device+0x28/0x3b
> [    4.017332]  [<ffffffff81302f4d>] driver_probe_device+0xda/0x202
> [    4.019226]  [<ffffffff81303075>] ? driver_probe_device+0x202/0x202
> [    4.021241]  [<ffffffff8130309a>] __device_attach+0x25/0x38
> [    4.023357]  [<ffffffff81301636>] bus_for_each_drv+0x80/0x85
> [    4.025480]  [<ffffffff81302e36>] device_attach+0x66/0x87
> [    4.027587]  [<ffffffff81302456>] bus_probe_device+0x34/0xe1
> [    4.029659]  [<ffffffff8130099f>] device_add+0x325/0x531
> [    4.031661]  [<ffffffff813744ca>] usb_new_device+0x450/0x66a
> [    4.033502]  [<ffffffff8107d9df>] ? trace_hardirqs_on+0xd/0xf
> [    4.035347]  [<ffffffff81565f03>] ? __mutex_unlock_slowpath+0x19d/0x1af
> [    4.037082]  [<ffffffff81374ff2>] hub_port_connect+0x4be/0x700
> [    4.038873]  [<ffffffff8137586a>] hub_events+0x636/0x7ba
> [    4.040210]  [<ffffffff81375a23>] hub_thread+0x35/0x16b
> [    4.041518]  [<ffffffff81075c8c>] ? prepare_to_wait_exclusive+0x6c/0x6c
> [    4.043361]  [<ffffffff813759ee>] ? hub_events+0x7ba/0x7ba
> [    4.045170]  [<ffffffff81059cb3>] kthread+0xd6/0xde
> [    4.046884]  [<ffffffff81059bdd>] ? __kthread_parkme+0x62/0x62
> [    4.048760]  [<ffffffff8156e0fc>] ret_from_fork+0x7c/0xb0
> [    4.050117]  [<ffffffff81059bdd>] ? __kthread_parkme+0x62/0x62
> [    4.051467] Code: 00 e9 c2 00 00 00 83 f8 03 41 8b 04 24 74 03 83 e8 03 85 c0 75 07 41 8b 54 24 10 01 13 48 98 41 8b 54 24 08 48 6b f0 28 48 01 de <01> 56 08 41 83 7d 1c 05 77 27 41 8b 55 1c ff 24 d5 80 cb 68 81
> [    4.057974] RIP  [<ffffffff8139abd4>] xhci_add_ep_to_interval_table+0xc8/0x172
> [    4.059737]  RSP <ffff880128e85608>
> [    4.061767] CR2: 0000000000000080
> [    4.063775] ---[ end trace 581dd718db50beb0 ]---
>
> 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.

> [    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
>
> So something about the PS2 adapter plugged into the dock gives it indigestion.
>
> ANy ideas?

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)

...for your build.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 15:55 ` Dan Williams
@ 2014-06-05 16:24   ` Valdis.Kletnieks
  2014-06-05 16:35     ` Dan Williams
  0 siblings, 1 reply; 8+ messages in thread
From: Valdis.Kletnieks @ 2014-06-05 16:24 UTC (permalink / raw)
  To: Dan Williams
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

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 #2: Type: application/pgp-signature, Size: 848 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 16:24   ` Valdis.Kletnieks
@ 2014-06-05 16:35     ` Dan Williams
  2014-06-05 17:29       ` Valdis.Kletnieks
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Williams @ 2014-06-05 16:35 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

On Thu, Jun 5, 2014 at 9:24 AM,  <Valdis.Kletnieks@vt.edu> 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...

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 16:35     ` Dan Williams
@ 2014-06-05 17:29       ` Valdis.Kletnieks
  2014-06-05 19:05         ` Dan Williams
  0 siblings, 1 reply; 8+ messages in thread
From: Valdis.Kletnieks @ 2014-06-05 17:29 UTC (permalink / raw)
  To: Dan Williams
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:

> 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...

Sure, no problem - just let me know what variant of linux-next you
want it applied against. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 17:29       ` Valdis.Kletnieks
@ 2014-06-05 19:05         ` Dan Williams
  2014-06-05 21:10           ` Valdis.Kletnieks
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Williams @ 2014-06-05 19:05 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

[-- Attachment #1: Type: text/plain, Size: 2641 bytes --]

On Thu, 2014-06-05 at 13:29 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 05 Jun 2014 09:35:48 -0700, Dan Williams said:
> 
> > 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...
> 
> Sure, no problem - just let me know what variant of linux-next you
> want it applied against. :)

This should apply to -next.  Use "git am -c", but I have attached it for
convenience as well.  Boots for me, but more importantly does it boot
for you :-).

8<------
Subject: usb: fix ->update_hub_device() vs hdev->maxchild

From: Dan Williams <dan.j.williams@intel.com>

Commit d8521afe3586 "usb: assign default peer ports for root hubs"
delayed marking a hub valid (set hdev->maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.

However, xhci_update_hub_device() in some cases depends on
hdev->maxchild already being set.  Do the minimal fix and move it after
the setting of hdev->maxchild.

Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 drivers/usb/core/hub.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..971d95745e2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1526,18 +1526,6 @@ static int hub_configure(struct usb_hub *hub,
 		dev_dbg(hub_dev, "%umA bus power budget for each child\n",
 				hub->mA_per_port);
 
-	/* Update the HCD's internal representation of this hub before khubd
-	 * starts getting port status changes for devices under the hub.
-	 */
-	if (hcd->driver->update_hub_device) {
-		ret = hcd->driver->update_hub_device(hcd, hdev,
-				&hub->tt, GFP_KERNEL);
-		if (ret < 0) {
-			message = "can't update HCD hub info";
-			goto fail;
-		}
-	}
-
 	ret = hub_hub_status(hub, &hubstatus, &hubchange);
 	if (ret < 0) {
 		message = "can't get hub status";
@@ -1593,6 +1581,18 @@ static int hub_configure(struct usb_hub *hub,
 	if (ret < 0)
 		goto fail;
 
+	/* Update the HCD's internal representation of this hub before khubd
+	 * starts getting port status changes for devices under the hub.
+	 */
+	if (hcd->driver->update_hub_device) {
+		ret = hcd->driver->update_hub_device(hcd, hdev,
+				&hub->tt, GFP_KERNEL);
+		if (ret < 0) {
+			message = "can't update HCD hub info";
+			goto fail;
+		}
+	}
+
 	usb_hub_adjust_deviceremovable(hdev, hub->descriptor);
 
 	hub_activate(hub, HUB_INIT);


[-- Attachment #2: valdis-crash-fix.patch --]
[-- Type: text/x-patch, Size: 2083 bytes --]

usb: fix ->update_hub_device() vs hdev->maxchild

From: Dan Williams <dan.j.williams@intel.com>

Commit d8521afe3586 "usb: assign default peer ports for root hubs"
delayed marking a hub valid (set hdev->maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.

However, xhci_update_hub_device() in some cases depends on
hdev->maxchild already being set.  Do the minimal fix and move it after
the setting of hdev->maxchild.

Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 drivers/usb/core/hub.c |   24 ++++++++++++------------
 1 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..971d95745e2a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1526,18 +1526,6 @@ static int hub_configure(struct usb_hub *hub,
 		dev_dbg(hub_dev, "%umA bus power budget for each child\n",
 				hub->mA_per_port);
 
-	/* Update the HCD's internal representation of this hub before khubd
-	 * starts getting port status changes for devices under the hub.
-	 */
-	if (hcd->driver->update_hub_device) {
-		ret = hcd->driver->update_hub_device(hcd, hdev,
-				&hub->tt, GFP_KERNEL);
-		if (ret < 0) {
-			message = "can't update HCD hub info";
-			goto fail;
-		}
-	}
-
 	ret = hub_hub_status(hub, &hubstatus, &hubchange);
 	if (ret < 0) {
 		message = "can't get hub status";
@@ -1593,6 +1581,18 @@ static int hub_configure(struct usb_hub *hub,
 	if (ret < 0)
 		goto fail;
 
+	/* Update the HCD's internal representation of this hub before khubd
+	 * starts getting port status changes for devices under the hub.
+	 */
+	if (hcd->driver->update_hub_device) {
+		ret = hcd->driver->update_hub_device(hcd, hdev,
+				&hub->tt, GFP_KERNEL);
+		if (ret < 0) {
+			message = "can't update HCD hub info";
+			goto fail;
+		}
+	}
+
 	usb_hub_adjust_deviceremovable(hdev, hub->descriptor);
 
 	hub_activate(hub, HUB_INIT);

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 19:05         ` Dan Williams
@ 2014-06-05 21:10           ` Valdis.Kletnieks
  2014-06-05 21:13             ` Dan Williams
  0 siblings, 1 reply; 8+ messages in thread
From: Valdis.Kletnieks @ 2014-06-05 21:10 UTC (permalink / raw)
  To: Dan Williams
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Thu, 05 Jun 2014 12:05:56 -0700, Dan Williams said:

> Subject: usb: fix ->update_hub_device() vs hdev->maxchild
>
> From: Dan Williams <dan.j.williams@intel.com>
>
> Commit d8521afe3586 "usb: assign default peer ports for root hubs"
> delayed marking a hub valid (set hdev->maxchild) until it had been fully
> configured and to enable the publishing of valid hubs to be serialized
> by usb_port_peer_mutex.
>
> However, xhci_update_hub_device() in some cases depends on
> hdev->maxchild already being set.  Do the minimal fix and move it after
> the setting of hdev->maxchild.
>
> Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Applied cleanly, booted without complaint, the keyboard that's behind
the PS2-USB converter works.

uname -r reports 3.15.0-rc8-next-20140605-dirty as expected.

So feel free to stick a Tested-By: on there. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linux-next crash in xhci_add_ep_to_interval
  2014-06-05 21:10           ` Valdis.Kletnieks
@ 2014-06-05 21:13             ` Dan Williams
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Williams @ 2014-06-05 21:13 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Alan Stern, Linux Kernel Mailing List, USB list,
	Greg Kroah-Hartman, Mathias Nyman

On Thu, Jun 5, 2014 at 2:10 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 05 Jun 2014 12:05:56 -0700, Dan Williams said:
>
>> Subject: usb: fix ->update_hub_device() vs hdev->maxchild
>>
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> Commit d8521afe3586 "usb: assign default peer ports for root hubs"
>> delayed marking a hub valid (set hdev->maxchild) until it had been fully
>> configured and to enable the publishing of valid hubs to be serialized
>> by usb_port_peer_mutex.
>>
>> However, xhci_update_hub_device() in some cases depends on
>> hdev->maxchild already being set.  Do the minimal fix and move it after
>> the setting of hdev->maxchild.
>>
>> Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>
> Applied cleanly, booted without complaint, the keyboard that's behind
> the PS2-USB converter works.
>
> uname -r reports 3.15.0-rc8-next-20140605-dirty as expected.
>
> So feel free to stick a Tested-By: on there. :)

Thank you, much appreciated!

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-06-05 21:13 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-05 15:22 linux-next crash in xhci_add_ep_to_interval Valdis Kletnieks
2014-06-05 15:55 ` Dan Williams
2014-06-05 16:24   ` Valdis.Kletnieks
2014-06-05 16:35     ` Dan Williams
2014-06-05 17:29       ` Valdis.Kletnieks
2014-06-05 19:05         ` Dan Williams
2014-06-05 21:10           ` Valdis.Kletnieks
2014-06-05 21:13             ` Dan Williams

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®