Messages in this thread | | | Date | Thu, 1 Jun 2006 09:10:18 +0200 | From | Ingo Molnar <> | Subject | Re: 2.6.17-rc5-mm1 |
| |
* Martin J. Bligh <mbligh@mbligh.org> wrote:
> >>>EIP is at check_deadlock+0x15/0xe0
i took your config and ran a few tests. Your kernel crashed here:
BUG: unable to handle kernel paging request at virtual address 22222232 CPU: 1 EIP: 0060:[<c012b6eb>] Not tainted VLI EFLAGS: 00010002 (2.6.17-rc5-mm1-autokern1 #1) EIP is at check_deadlock+0x15/0xe0 eax: 22222222 ebx: 00000001 ecx: d4996000 edx: 00000001 esi: d686f550 edi: 22222222 ebp: 22222222 esp: d5bdfec8 ds: 007b es: 007b ss: 0068 Process mkdir09 (pid: 18867, threadinfo=d5bdf000 task=d5c0e000) Stack: 00000000 d686f550 d3960568 22222222 c012b77b d3960568 d5bdf000 d5bdff00 d5c0e000 c012b922 d5bdff48 d3960568 00000246 c02d50de d5bdff00 d5bdff00 11111111 11111111 d5bdff00 ffffff9c d5bdff48 00000000 d5bdff48 ffffffef
which is:
(gdb) list *0xc012a26e 0xc012a26e is in check_deadlock (kernel/mutex-debug.c:98). 93 struct task_struct *task; 94 95 if (!debug_locks) 96 return 0; 97 98 ti = lock->owner; 99 if (!ti) 100 return 0; 101 102 task = ti->task; (gdb)
i.e. "lock" was 0x22222222. I have not changed this particular deadlock detection code for some time and it's been stable for many weeks. (the changes in -mm1 were in another area of mutex-debug.c, and even those mostly removed code and didnt add new logic)
the stack looks weird:
Stack: 00000000 d686f550 d3960568 22222222 c012b77b d3960568 d5bdf000 d5bdff00 d5c0e000 c012b922 d5bdff48 d3960568 00000246 c02d50de d5bdff00 d5bdff00 11111111 11111111 d5bdff00 ffffff9c d5bdff48 00000000 d5bdff48 ffffffef
where does the 0x11111111 and the 0x22222222 come from? It doesnt ring any bells in terms of kernel-internal magic or poison values. My impression is that there's some other badness going on (some sort of memory corruption) and the mutex debugging code just got caught up in the crossfire.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |