| Summary: | =sys-kernel/gentoo-sources-{3.7.3,3.8.0} - __anon_vma_interval_tree_subtree_search - unable to handle kernel NULL pointer dereference at 00000048 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | YoungFrog <theonewiththeevillook> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
YoungFrog
2013-02-25 14:57:58 UTC
> (Similar symptoms to https://bugs.gentoo.org/show_bug.cgi?id=431048, but these kernel bugs all look similar to me so i file a new report) You need to compare the call traces to see how they are different. > Can't reproduce : I tried switching from emacs to FF again but there is obviously something else involved; Would love a reproducible case, preferably if another person experiences this as well (so we can find what is common); for now it could be about anything and not necessarily happen in the same location in the code. If someone is able to reproduce this, please reply; otherwise this might as well be a random hardware issue. (In reply to comment #2) > If someone is able to reproduce this, please reply; otherwise this might as > well be a random hardware issue. FWIW, it happened once again, I was switching from FF to Emacs this time (but I hardly have any other app running except Thunderbird, so this is biaised) and the backtrace is hereunder. Most notable difference is that the kernel version is now 3.8.0 -- other numbers change too but I assume that was to be expected with a different kernel. I'll not report anymore on this unless I have something actually useful (which, I'm afraid, this is not) ; but this at least shows how rare it happens. This is also the occasion for me to thank you for the time you took to have a look. [19080.786106] BUG: unable to handle kernel NULL pointer dereference at 0000004c [19080.786168] IP: [<c10d9c60>] __anon_vma_interval_tree_subtree_search+0x1f/0x47 [19080.786224] *pde = 00000000 [19080.786245] Oops: 0000 [#1] SMP [19080.786271] Modules linked in: radeon drm_kms_helper ttm i2c_piix4 [19080.786323] Pid: 634, comm: kswapd0 Tainted: G W 3.8.0-gentoo #1 Gigabyte Technology Co., Ltd. GA-880GM-UD2H/GA-880GM-UD2H [19080.786403] EIP: 0060:[<c10d9c60>] EFLAGS: 00010246 CPU: 0 [19080.786441] EIP is at __anon_vma_interval_tree_subtree_search+0x1f/0x47 [19080.786485] EAX: 00000000 EBX: f52fdbc0 ECX: 0000002f EDX: 0000002f [19080.786527] ESI: 0000002f EDI: 0000002f EBP: f5b3fdc4 ESP: f5b3fdb8 [19080.786569] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [19080.786605] CR0: 8005003b CR2: 0000004c CR3: 0191f000 CR4: 000007d0 [19080.786647] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [19080.786688] DR6: ffff0ff0 DR7: 00000400 [19080.786715] Process kswapd0 (pid: 634, ti=f5b3e000 task=f5a2f470 task.ti=f5b3e000) [19080.786764] Stack: [19080.786778] f52fd910 00000000 f5b3ff14 f5b3fdd0 c10da0ec f76ceae0 f5b3fdf8 c10e34bd [19080.786840] d8b64c60 00000000 f45698c0 0000002f 00000001 f76ceaf4 f76ceae0 f5b3ff14 [19080.786901] f5b3fe54 c10d060a f5b3fe44 c18998c4 c18998c0 00000015 ffffffe0 c18998c0 [19080.786962] Call Trace: [19080.786982] [<c10da0ec>] anon_vma_interval_tree_iter_first+0x19/0x1c [19080.787027] [<c10e34bd>] page_referenced+0x8b/0x16e [19080.787063] [<c10d060a>] shrink_active_list+0x16c/0x21d [19080.787100] [<c10d14fc>] shrink_lruvec+0x3a4/0x3a7 [19080.787133] [<c10d1976>] kswapd+0x477/0x672 [19080.787163] [<c10d1976>] ? kswapd+0x477/0x672 [19080.787196] [<c106b18d>] ? add_wait_queue+0x35/0x35 [19080.787231] [<c106aba4>] kthread+0x6b/0x70 [19080.787260] [<c10d14ff>] ? shrink_lruvec+0x3a7/0x3a7 [19080.787296] [<c15e75b7>] ret_from_kernel_thread+0x1b/0x28 [19080.787333] [<c106ab39>] ? kthread_freezable_should_stop+0x36/0x36 [19080.787374] Code: f0 e8 96 ff ff ff 89 43 0c 5b 5d c3 55 89 e5 57 89 cf 56 89 d6 53 89 c3 eb 03 8d 58 f0 8b 43 18 85 c0 74 05 3b 70 0c 76 f1 8b 03 <39> 78 4c 77 1a e8 9e fe ff ff 39 c6 76 13 8b 5b 14 85 db 74 0a [19080.787582] EIP: [<c10d9c60>] __anon_vma_interval_tree_subtree_search+0x1f/0x47 SS:ESP 0068:f5b3fdb8 [19080.787647] CR2: 000000000000004c [19080.805068] ---[ end trace a6ff6e9caa0954f0 ]--- Will try to go through the call trace and see if there's an obvious error there, as well research it upstream with findings; makes me wonder if this still happens on 3.9.2... The code is quite low level which makes it hard to follow, I've instead digged into the commit history to see if this has been fixed over the last months. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?id=v3.8 v3.8 was released on 18 February. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?qt=grep&q=anon_vma There have been some commits, mostly on 24 February, dealing with anon_vma. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=bc56620b493496b8a6962080b644ccc537f4d526 This commit in peculiar seems somewhat interesting; first of all, it is in x86 just like your bug, second, he talks about a pointer that has no purpose (possibly causing the NULL pointer dereference perhaps?!) and in particular he tells he forgot about this (which might mean there was a problem in one of his earlier commits) so it could possibly fix something. So, could you just try the latest kernel and see if you can still reproduce? I compiled gentoo-sources 3.10.1 just now and will select it at my next reboot ; don't hold your breath though, since the bug doesn't happen very often (I think it happened only once since my latest report.) It's been awhile and I'm hopeful this was resolved with later kernels. If not, please comment here and I will reopen. |
