lkml.org 
[lkml]   [1998]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject2.1.99 oops
    2.1.99 seemed to last long on my system than other 2.1.x kernels and it
    didn't even hard lock. I only tried it once, so that doesn't meen it won't
    lock.

    general protection: 3000
    CPU: 0
    EIP: 0010:[<c0109963>]
    EFLAGS: 00010246
    eax: 00000001 ebx: 00000002 ecx: c6fa3000 edx: 00000002
    esi: c6fa3000 edi: 00001000 ebp: 00000000 esp: c5c1bec4
    ds: 0000 es: 0018 ss: 0018
    Process cat (pid: 770, process nr: 51, stackpage=c5c1b000)
    Stack: c6fa3000 0804b677 00000050 c018b9d8 c5c1bef0 0804b677 00000050 00001000
    00000000 c6fa3000 00000000 00000000 00000000 00000000 00000000 00000000
    00000002 00000000 c01937aa c6fa3000 00000000 c5c1bf23 00000001 00000000
    Call Trace: [<c018b9d8>] [<c01937aa>] [<c018b983>] [<c018d800>] [<c018d840>] [<c01897e5>] [<c018d714>]
    [<c0123c20>] [<c0109880>]
    Code: 07 83 c4 04 cf 68 40 99 10 c0 e9 fa dc 00 00 89 f6 68 84 98

    Using `/mnt/hda1/2.1.99-map' to map addresses to symbols.

    >>EIP: c0109963 <ret_from_intr+23/28>
    Trace: c018b9d8 <opost_block+48/178>
    Trace: c01937aa <con_put_char+1e/28>
    Trace: c018b983 <opost+1b3/1c0>
    Trace: c018d800 <write_chan+ec/1d0>
    Trace: c018d840 <write_chan+12c/1d0>
    Trace: c01897e5 <tty_write+121/178>
    Trace: c018d840 <write_chan+12c/1d0>
    Trace: c0123c20 <sys_write+b4/10c>
    Trace: c0109880 <system_call+38/3c>
    Code: c0109963 <ret_from_intr+23/28>
    Code: c0109963 <ret_from_intr+23/28> 07 popl %es
    Code: c0109964 <ret_from_intr+24/28> 83 c4 04 addl $0x4,%esp
    Code: c0109967 <ret_from_intr+27/28> cf iret
    Code: c0109968 <handle_bottom_half> 68 40 99 10 c0 pushl $0xc0109940
    Code: c0109973 <handle_bottom_half+b/c> e9 fa dc 00 00 jmp c011766c <do_bottom_half>
    Code: c0109978 <reschedule+4/c> 89 f6 movl %esi,%esi
    Code: c010997a <reschedule+6/c> 68 84 98 00 90 pushl $0x90009884
    Code: c0109985 <divide_error+5/8> 90 nop
    Code: c0109986 <divide_error+6/8> 90 nop

    I did receive a few screen fulls of this type of error,
    attempt to access beyond end of device
    16:01: rw=0, want=185207049, limit=128240
    followed by I assume to be about the same number of this error,
    EXT2-fs error (device 16:01): ext2_free_blocks: Freeing blocks not in
    datazone - block = 2138996092, count = 1

    Most of the time I was dd'ing from /dev/zero to a file on the different
    harddrives, I was able to delete the file from the harddrive that gave the
    errors and unmount it. I even ran e2fsck on it, it corrected errors and
    after I rebooted I ran e2fsck which did not find any errors. I don't think
    the errors from the harddrive and the oops are related, I've been wondering
    if the drive is going out for some time. The other ide drive drive is on a
    different controller and showed no problems same with the scsi drives. The
    oops followed a long time after the ide drive errors and left one of my
    bash shells in the D state which couldn't be killed. I was able to
    shutdown and reboot without further problems. I was at console the whole
    time, I was not in X at all.

    I seem to always have problems with middle to late 2.1.x, I don't think
    I've logged over a day of continuous uptime, but extremely rarely have
    problems with 2.0.x.

    AMD K5 PR133
    Tyan 1653D, Tomcat III
    Intel 82439HX, 82371SB chipset
    128 megs memory,
    NCR53C810 using BSD ported driver
    Both IDE and SCSI harddrives
    NE2000 compatible ISA
    3Com 3c503
    gcc 2.7.2.3

    --
    +---------------------------------+
    | David Fries |
    | dfries@mail.win.org |
    +---------------------------------+

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:4.621 / U:0.608 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site