Bad hardware.  Do you get signal 11's when making programs?

Lookup memtest at freshmeat.net and see if your memory is bad.

On Thu, Mar 30, 2000 at 12:14:48PM +0000, Sandor Dibuz wrote:
> Hiya all,
> 
> Somebody please help me! I was fighting for almost two weeks, but stumped
> by now.
> 
> Simply can't keep my system up for more then a few hours or a day without
> getting kernel Oops. This is the ha3pmf.pmmf.hu gateway. Dumped TNOS two
> weeks ago and I have this problem since then. I've never got such
> complaints before, though TNOS was not stable enough, spammable, etc.
> Usually the first victim is mheardd, then comes netromd and the system
> crashes. Worst, it's in the college, after a halt I always have to go up
> there, fiddle this or that, come down and cross my fingers...
> 
> 
> Last two Oops:
> 
> 
> Warning: kfree_skb passed an skb still on a list (from c017b509).
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> current->tss.cr3 = 018c7000, %cr3 = 018c7000
> *pde = 00000000
> Oops: 0002
> CPU:    0
> EIP:    0010:[skb_recv_datagram+355/416]
> EFLAGS: 00010047
> eax: c18350d0   ebx: 00000000   ecx: 00000246   edx: 00000000
> esi: c18c9ddc   edi: c18c8000   ebp: c18ea514   esp: c18c9dcc
> ds: 0018   es: 0018   ss: 0018
> Process mheardd (pid: 1987, process nr: 19, stackpage=c18c9000)
> Stack: c18c9e84 c18c9f48 c18352b0 c0187770 c18c8000 c19273d4 00000301 00050f3b 
>        00000400 c0171f79 c18ea4d0 00000000 00000000 c18c9e20 c19273bc 000005dc 
>        c18c9e84 c18c9f48 00000001 00000000 c18ea4d0 c013c863 00000301 00050f3b 
> Call Trace: [multwrite_intr+0/172] [packet_recvmsg+81/252] [inode_getblk+71/408] 
>[sock_recvmsg+65/188] [sys_recvfrom+172/264] [free_page_and_swap_cache+101/108] 
>[do_munmap+537/560] 
>        [sys_socketcall+394/524] [sys_munmap+46/72] [common_interrupt+24/32] 
>[sys_time+19/32] [system_call+52/56] [startup_32+43/285] 
> Code: 89 6a 04 89 55 00 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7 
> 
> 
> Warning: kfree_skb passed an skb still on a list (from c017b509).
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> current->tss.cr3 = 01cea000, %cr3 = 01cea000
> *pde = 00000000
> Oops: 0002
> CPU:    0
> EIP:    0010:[skb_recv_datagram+355/416]
> EFLAGS: 00010047
> eax: c139daa0   ebx: 00000000   ecx: 00000246   edx: 00000000
> esi: 00000200   edi: c1c99e84   ebp: c1fbb2a4   esp: c1c99dcc
> ds: 0018   es: 0018   ss: 0018
> Process netromd (pid: 1976, process nr: 11, stackpage=c1c99000)
> Stack: c1c99e84 c1c99f48 c139d820 c1d6ec80 00000286 00000000 00000000 c1d6ec80 
>        00000296 c0171f79 c1fbb260 00000000 00000000 c1c99e20 c1a15c3c 00000200 
>        c1c99e84 c1c99f48 c1d6ec80 c1d6ec80 c1fbb260 00000010 c1d6ec80 c1fe3c68 
> Call Trace: [packet_recvmsg+81/252] [sock_recvmsg+65/188] [nr_release+73/240] 
>[sys_recvfrom+172/264] [free_pages+39/44] [free_wait+104/116] [do_select+481/504] 
>        [do_select+437/504] [sys_select+1103/1296] [sys_socketcall+394/524] 
>[startup_32+43/285] [sys_time+19/32] [system_call+52/56] [startup_32+43/285] 
> Code: 89 6a 04 89 55 00 c7 00 00 00 00 00 c7 40 04 00 00 00 00 c7 
> 
> 
> Details:
> 
> - old 486DX2/66 CPU, 32M RAM, Baycom USCC (only two 1200Bd on-board modems
>   used now), SMC Ultra NIC and a small 540M hd
> - kernel: 2.2.15pre14, distribution: Debian potato
> - related softwares: libax25-0.0.7, ax25-tools-0.0.5 (with Tomi's netrom
>   patch), ax25-apps-0.0.4, node-0.3.0
> - running ax25ipd, netromd, ax25d, mheardd
> - no special services on the PC: smtp (postfix), ftp (proftpd), etc.
> 
> 
> What I tried up to now:
> 
> - back to kernel-2.2.14 for awhile
> - replaced CPU and RAM
> - replaced motherboard with two different types, latter was a P1/133
> - originally used Debian potato's libax25, ax25-apps, ax25-tools and node
>   packages, then compiled fresh ones from sources
> - also tried awznode-v0.4-pre2 instead of node-0.3.0, thought it has
>   nothing to do with the issue I'm afraid
> 
> None of them helped.
> 
> I can try to get symbols by ksymoops if a kind fellow would like to
> parse, unfortunatelly I'm not a coder.
> 
> One more observation: using listen usually results earlier Oops.
> 
> 
> Any and all your ideas are welcome! (Except of drilling holes on the box
> to let oops out of the box ;-) (c)Terry?)
> 
> 
> Thanks, 73... Sanyi
> 
> -- 
> Sandor Dibuz  | email: [EMAIL PROTECTED]
> Pecs, Hungary | AX.25: [EMAIL PROTECTED]
> 
> 

Reply via email to