Re: 1.3.27 Ooops

James H. Cloos Jr. (cloos@JHCloos.COM)
Sun, 17 Sep 1995 07:29:30 -0500


>>>>> "|" == Stephen Sayer <ssayer@hijinx.com> writes:

|> Got this oops right after clicking a link in Netscape 1.1N. Appeared to hang up
|> inetd pretty good (specifically open imapd connections).

|> Here's the ksymoops output followed by the /var/adm/messages log:

|> EIP: 14549c T _tcp_rcv+24c/23d0
|> Trace: 13e48c T _ip_rcv+51c/5d0
|> Trace: 1386d6 T _net_bh+116/160
|> Trace: 1170c6 T _do_bottom_half+3e/a8
|> Trace: 10a77d t handle_bottom_half+d/20
|> Trace: 1c002b t _def_tmr_ioctl+13/1f0

|> Sep 16 02:44:58 voyager kernel: Oops: 0002
|> Sep 16 02:44:58 voyager kernel: EIP: 0010:0014549c
|> Sep 16 02:44:58 voyager kernel: EFLAGS: 00010006
|> Sep 16 02:44:58 voyager kernel: eax: 024001a1 ebx: 003faf1c ecx: 78fd0000
|> edx: 00000006
|> Sep 16 02:44:58 voyager kernel: esi: 01027414 edi: 04805aa5 ebp: 012c20f0
|> esp: 013f4ee8
|> Sep 16 02:44:58 voyager kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
|> ss: 0018
|> Sep 16 02:44:58 voyager kernel: Process netscape (pid: 803, process nr: 47,
|> stackpage=013f4000)
|> Sep 16 02:44:58 voyager kernel: Stack: 001d3410 012c20f0 003faf1c 003faeec
|> 00000000 00000014 003faf1c 003faeec
|> Sep 16 02:44:58 voyager kernel: 003faf00 012c2024 00000000 01031831
|> 003faf00 04805aa5 00000014 012c0000
|> Sep 16 02:44:58 voyager kernel: 00000000 0013e48c 003faf1c 012c20f0
|> 00000000 6551c7cd 00000014 04805aa5
|> Sep 16 02:44:58 voyager kernel: Call Trace: 0013e48c 001386d6 001170c6 0010a77d
|> 001c002b
|> Sep 16 02:44:58 voyager kernel: Code: 89 18 52 9d fb 31 c0 5b 5e 5f 5d 83 c4 34
|> c3 90 90 90 90 90
|> Sep 16 02:44:58 voyager kernel: Aiee, killing interrupt handler

Yes, this is the same one I posted previously. We get these almost
daily in .3.15 thru .3.25. (.3.26 died as soon as dummy.o was
insmod(8)ed, and .3.27 has only been up for 1 (weekend) day so far,
but it seems pretty constant.

We usually notice it when the wire gets really hot (our hub usually
indicates over 50% utilization and typically 3 to 6 percent collisions).

We are using 3c509 cards, if it is at all driver related. (Didn't I
read in the ethernet faq that that 509 driver didn't use all of the
buffer on the newer cards? Related?)

The bug may be tweaked when the backlog for a port exceeds the number
allowed. I tried a kernel with the backlog trunction set to 255, but
the Oopses persisted. (The box we see this msot on is running our web
server.)

-JimC

-- 
James H. Cloos, Jr.	include <std/qotd>
James.Cloos@JHCloos.COM	include <std/disclaimers.h>
Work: cloos@io.com	URL:	http://www.jhcloos.com/~cloos/
LPF,Usenix,SAGE,ISOC	Snail:	POBox 18122 Austin, TX 78760-8122