Messages in this thread | | | Date | Mon, 21 Feb 2000 13:41:06 -0500 (EST) | From | Richard A Nelson <> | Subject | Re: Oops - 2.2.7ac4 - 2.2.15pre5 ... networking? |
| |
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/
| |