On Mon, Jul 4, 2016 at 4:26 PM, Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
> Hi
>
> AceLan Kao can get his DELL XPS 13 laptop to hang by plugging/un-plugging
> a USB 3.1 key via thunderbolt port.
>
> Allocating memory fails after this, always pointing to NULL pointer or
> page request failing in get_freepointer() called by
> kmalloc/kmem_cache_alloc.
>
> Unplugging a usb type-c device from the thunderbolt port on Alpine Ridge
> based
> systems like this one will hotplug remove PCI bridges together with the USB
> xhci
> controller behind them.
>
> [ 61.969221] usb 4-1: USB disconnect, device number 2
> [ 61.992892] xhci_hcd 0000:39:00.0: Host not halted after 16000
> microseconds.
> [ 61.994002] xhci_hcd 0000:39:00.0: USB bus 4 deregistered
> [ 61.994013] xhci_hcd 0000:39:00.0: remove, state 4
> [ 61.994022] usb usb3: USB disconnect, device number 1
> [ 61.995317] xhci_hcd 0000:39:00.0: USB bus 3 deregistered
> [ 61.995949] pci_bus 0000:03: busn_res: [bus 03] is released
> [ 61.996022] pci_bus 0000:04: busn_res: [bus 04-38] is released
> [ 62.016460] pci_bus 0000:39: busn_res: [bus 39] is released
> [ 62.016515] pci_bus 0000:02: busn_res: [bus 02-39] is released
> [ 62.103618] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000001
> [ 62.103651] IP: [<ffffffff811eb67b>] kmem_cache_alloc_trace+0x7b/0x1f0
> [ 62.103681] PGD 0
> [ 62.103689] Oops: 0000 [#1] SMP
> [ 62.103702] Modules linked in:
>
> [ 62.104303] CPU: 3 PID: 993 Comm: Xorg Tainted: G OE
> 4.4.0-28-generic #47-Ubuntu
> [ 62.104345] Hardware name: Dell Inc. XPS 13 9360/ , BIOS 0.1.7
> 06/22/2016
> [ 62.104383] task: ffff88006f3a8000 ti: ffff880078fa0000 task.ti:
> ffff880078fa0000
> [ 62.104420] RIP: 0010:[<ffffffff811eb67b>] [<ffffffff811eb67b>]
> kmem_cache_alloc_trace+0x7b/0x1f0
> [ 62.104468] RSP: 0018:ffff880078fa3c70 EFLAGS: 00010202
> [ 62.104495] RAX: 0000000000000000 RBX: 00000000024000c0 RCX:
> 0000000000010d87
> [ 62.104530] RDX: 0000000000010d86 RSI: 00000000024000c0 RDI:
> 0000000000019f80
> [ 62.104565] RBP: ffff880078fa3cb0 R08: ffff88017e599f80 R09:
> ffff880179801b00
> [ 62.104603] R10: 0000000000000001 R11: 000000000000007c R12:
> 00000000024000c0
> [ 62.104641] R13: ffffffffc00c1b1a R14: ffff88017485a000 R15:
> ffff880179801b00
> [ 62.104680] FS: 00007fe6a0241a00(0000) GS:ffff88017e580000(0000)
> knlGS:0000000000000000
> [ 62.104722] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 62.104752] CR2: 0000000000000001 CR3: 0000000177234000 CR4:
> 00000000003406e0
> [ 62.104789] Stack:
> [ 62.104801] ffff880078fa3cd8 ffffffff813ec8ee 0000000000000028
> ffff8801759d4fd8
> [ 62.104847] ffff8801785d8b00 ffff880174f9be60 ffff88017485a000
> 000000000000007c
> [ 62.104892] ffff880078fa3cd8 ffffffffc00c1b1a ffff8801759d4fc0
> ffff880174f9be00
> [ 62.104938] Call Trace:
> [ 62.104956] [<ffffffff813ec8ee>] ? idr_alloc+0x9e/0x110
> [ 62.105005] [<ffffffffc00c1b1a>] drm_vma_node_allow+0x2a/0xc0 [drm]
> [ 62.105047] [<ffffffffc00a7d43>] drm_gem_handle_create_tail+0xc3/0x190
> [drm]
> [ 62.105088] [<ffffffffc00a7e45>] drm_gem_handle_create+0x35/0x40 [drm]
> [ 62.105145] [<ffffffffc01cf531>] i915_gem_userptr_ioctl+0x271/0x350
> [i915_bpo]
> [ 62.105190] [<ffffffffc00a8742>] drm_ioctl+0x152/0x540 [drm]
> [ 62.105235] [<ffffffffc01cf2c0>] ?
> __i915_gem_userptr_get_pages_worker+0x320/0x320 [i915_bpo]
> [ 62.105262] [<ffffffff81220b6f>] do_vfs_ioctl+0x29f/0x490
> [ 62.105281] [<ffffffff81701610>] ? __sys_recvmsg+0x80/0x90
> [ 62.105298] [<ffffffff81220dd9>] SyS_ioctl+0x79/0x90
> [ 62.105319] [<ffffffff818276b2>] entry_SYSCALL_64_fastpath+0x16/0x71
> [ 62.105346] Code: 08 65 4c 03 05 2f eb e1 7e 49 83 78 10 00 4d 8b 10 0f
> 84 21 01 00 00 4d 85 d2 0f 84 18 01 00 00 49 63 41 20 48 8d 4a 01 49 8b 39
> <49> 8b 1c 02 4c 89 d0 65 48 0f c7 0f 0f 94 c0 84 c0 74 bb 49 63
> [ 62.105520] RIP [<ffffffff811eb67b>] kmem_cache_alloc_trace+0x7b/0x1f0
> [ 62.105543] RSP <ffff880078fa3c70>
> [ 62.105554] CR2: 0000000000000001
> [ 62.113016] ---[ end trace 4f9991d2eebd1637 ]---
>
> (gdb) list *(kmem_cache_alloc_trace+0x7b)
> 0xffffffff811eb67b is in kmem_cache_alloc_trace
> (/build/linux-BvkamA/linux-4.4.0/mm/slub.c:247).
> 242 return 1;
> 243 }
> 244
> 245 static inline void *get_freepointer(struct kmem_cache *s, void
> *object)
> 246 {
> 247 return *(void **)(object + s->offset);
> 248 }
> 249
> 250 static void prefetch_freepointer(const struct kmem_cache *s, void
> *object)
> 251 {
>
> More logs can be found at
> https://bugzilla.kernel.org/show_bug.cgi?id=120241
>
> This log was from a 4.4 based ubuntu kernel, but the same issue was
> reproduced
> with 4.7-rc5. Call trace often point to various graphics related drivers,
> but
> also xhci and acpi_hotplug_work_fn.
> Only thing they have in common is that they fail while trying to allocate
> memory.
>
> A log of acpi_hotplug_work_fn failing to allocate memory while removing pci
> devices:
> https://bugzilla.kernel.org/attachment.cgi?id=221561
>
> I've been looking at this from xhci perspective, but it starts to go too
> deep
> into mm, pci hotplug etc for my understanding.
>
> Any ideas?
Are you able to reproduce this by unplugging and replugging the entire
Thunderbolt link?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>