[lkml]   [2002]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectOops with 2.4.20-rc4-ac1
    Hash: SHA1


    I have a machine with few hard discs connected via 3 different IDE
    controllers. I've decided to use recent -ac kernel to test its functionality
    with this hardware and it seems to be working to some point... I'm testing
    stability of the configuration running multiple copies of badblocks -w for all
    my hdds, and after 2 hours of testing it said:
    kernel BUG at buffer.c:510!
    invalid operand: 0000
    CPU: 0
    EIP: 0010:[<c013acae>] Not tainted
    EFLAGS: 00010286
    eax: db000000 ebx: 00000002 ecx: dbdef9c0 edx: c02ccc8c
    esi: dbdef9c0 edi: 00000001 ebp: dbdefec0 esp: d5827ee4
    ds: 0018 es: 0018 ss: 0018
    Process badblocks (pid: 242, stackpage=d5827000)
    Stack: 00000002 c013b5fb dbdef9c0 00000002 dbdef9c0 00000800 c013c172 dbdef9c0
    00000400 00000000 00000000 00000400 00000800 00000400 c013c7f9 dfe02340
    c115818c 00000400 00000800 c012bebb c115818c 00000400 00000800 00000800
    Call Trace: [<c013b5fb>] [<c013c172>] [<c013c7f9>] [<c012bebb>] [<c0139593>]

    Code: 0f 0b fe 01 92 e5 23 c0 8b 02 85 c0 75 07 89 0a 89 49 24 8b

    Because it's "kernel BUG", I've decided to report this to you. One of
    badblocks processes segfaulted - it was checking /dev/hdj, which is connected
    through on-board VIA controller, and the badblocks checking /dev/hdi on the
    same cable at the same time didn't produce any errors, so it looks rather as a
    kernel problem, not a hardware-related one. I'm including ksymoops output:

    >>EIP; c013acae <file_fsync+23e/320> <=====

    >>eax; db000000 <___strtok+1ad0bd2c/20563d2c>
    >>ecx; dbdef9c0 <___strtok+1bafb6ec/20563d2c>
    >>edx; c02ccc8c <zone_table+f64/1c50>
    >>esi; dbdef9c0 <___strtok+1bafb6ec/20563d2c>
    >>ebp; dbdefec0 <___strtok+1bafbbec/20563d2c>
    >>esp; d5827ee4 <___strtok+15533c10/20563d2c>

    Trace; c013b5fb <set_buffer_flushtime+7b/a0>
    Trace; c013c172 <create_empty_buffers+662/680>
    Trace; c013c7f9 <block_prepare_write+79/80>
    Trace; c012bebb <generic_file_write+46b/28a0>
    Trace; c0139593 <default_llseek+3d3/ca0>
    Trace; c0107277 <__up_wakeup+1287/1660>

    Code; c013acae <file_fsync+23e/320>
    00000000 <_EIP>:
    Code; c013acae <file_fsync+23e/320> <=====
    0: 0f 0b ud2a <=====
    Code; c013acb0 <file_fsync+240/320>
    2: fe 01 incb (%ecx)
    Code; c013acb2 <file_fsync+242/320>
    4: 92 xchg %eax,%edx
    Code; c013acb3 <file_fsync+243/320>
    5: e5 23 in $0x23,%eax
    Code; c013acb5 <file_fsync+245/320>
    7: c0 8b 02 85 c0 75 07 rorb $0x7,0x75c08502(%ebx)
    Code; c013acbc <file_fsync+24c/320>
    e: 89 0a mov %ecx,(%edx)
    Code; c013acbe <file_fsync+24e/320>
    10: 89 49 24 mov %ecx,0x24(%ecx)
    Code; c013acc1 <file_fsync+251/320>
    13: 8b 00 mov (%eax),%eax

    I hope someone on the list knows what's happening and finds this information
    useful. I'm not subscribed, but I'll check in the archives if someone is
    answering without Cc: to me :)

    P.S. I'm not using taskfile IO. Maybe I should?
    Version: GnuPG v1.2.0 (GNU/Linux)

    -----END PGP SIGNATURE-----

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:31    [W:0.022 / U:1.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site