This was a bizzare mess ! But there is new (important?) info !
HDware:
K6/2-350, ASUS P5A 1.03, 128M, BT-958 (Buslogic F/W), 2 2G Wide drives
USR 56K internal modem, Linksys LNE100TX
Suddenly started OOPSing ~ mid December and hasn't been stable since !
Finally found that the oopsen almost always happen whilst fetchmail
is pulling mail from my ISP. This gave me a way to try and do further
diagnostics (as time rarely permitted).
I wound up swapping most everything...
K6/2-475, ASUS P5A 1.06, 2x64M, BT-958 (Buslogic F/W), 2 2G Wide drives
USR 56K internal modem, Linksys LNE100TX
Finally, in a fit of frustration, I yanked the only thing that hasn't
been replaced or swapped out/in: the SCSI controller/DASD.
I put a IDE drive in, copied the SCSI drives to it and rebooted. The
box has been running with no problems since (Yes, a few days is a
records since mid December ;-{ ).
Tonight I'll try the SCSI components on a K6/2-233 box and see if it
stays up!?!?
Like all my other OOPS, and several I've seen on the list,
the OOPS has two components:
*) The original OOPS
Unable to handle kernel paging request at virtual address 090f0e37
current->tss.cr3 = 03c5b000, %cr3 = 03c5b000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0167bd0>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: c7e80000 ebx: 090f0e07 ecx: c02099b0 edx: 00000000
esi: 00000001 edi: ffffffff ebp: 0000297f esp: c3c57f6c
ds: 0018 es: 0018 ss: 0018
Process prime-net (pid: 770, process nr: 36, stackpage=c3c57000)
Stack: ffffffff 00d5c98b 00000000 c0167fe9 c02104b0 00000000 c0167fb8 00000000
c3c57fa4 c0112de9 00000000 00000001 c024c714 00000000 c3c57fbc c01195c9
00000000 401d75c0 4014cf60 c010b219 bffff964 c010aee8 00000000 000aa88e
Call Trace: [<c0167fe9>] [<c0167fb8>] [<c0112de9>] [<c01195c9>] [<c010b219>] [<c010aee8>]
Code: 83 7b 30 00 0f 85 ee 00 00 00 8a 43 77 84 c0 0f 84 e3 00 00
>>EIP; c0167bd0 <tcp_keepalive+38/178> <=====
Trace; c0167fe9 <tcp_sltimer_handler+31/70>
Trace; c0167fb8 <tcp_sltimer_handler+0/70>
Trace; c0112de9 <timer_bh+2e9/330>
Trace; c01195c9 <do_bottom_half+49/64>
Trace; c010b219 <do_IRQ+39/40>
Trace; c010aee8 <common_interrupt+18/20>
Code; c0167bd0 <tcp_keepalive+38/178>
00000000 <_EIP>:
Code; c0167bd0 <tcp_keepalive+38/178> <=====
0: 83 7b 30 00 cmpl $0x0,0x30(%ebx) <=====
Code; c0167bd4 <tcp_keepalive+3c/178>
4: 0f 85 ee 00 00 00 jne f8 <_EIP+0xf8> c0167cc8 <tcp_keepalive+130/178>
Code; c0167bda <tcp_keepalive+42/178>
a: 8a 43 77 mov 0x77(%ebx),%al
Code; c0167bdd <tcp_keepalive+45/178>
d: 84 c0 test %al,%al
Code; c0167bdf <tcp_keepalive+47/178>
f: 0f 84 e3 00 00 00 je f8 <_EIP+0xf8> c0167cc8 <tcp_keepalive+130/178>
Aiee, killing interrupt handler
*) A plethora of subsequent OOPSen, apparently caused by invalid
(and unchecked) pointers
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0002
-- Rick Nelson Life'll kill ya -- Warren Zevon Then you'll be dead -- Life'll kill ya- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:28 EST