lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-06-01 09:12    [W:0.024 / U:47.180 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site