arpd problems

Nathan Spande (
Tue, 26 Nov 1996 18:13:11 -0600

Hello once again, one and all. I haven't heard anything from my first
few posts regarding my arpd oopses, but I am hoping that is just a
result of lag time with vger. I have some more data, this time there
should be much more ability to trace things.

The problem: I get an oops (reproduced below, with ksymoops output)
from arpd when doing random network things.

The testing done: I didn't start arpd from my rc.inet2 script, as I
usually do. I recompiled it (arpd 1.02) and enabled debugging. I
then ran it (as root) in one vc and did network things in another. It
was stable for a short period of time, and then gave me the oops shown
below. Luckily, arpd also spat out a bit of information.

As a final comment, something that may or may not be related to this
problem, I have started getting these messages in my logs. Here is a
sample from a recent log:
Nov 21 16:42:03 puck kernel: Socket destroy delayed (r=0 w=248)
Nov 21 20:11:54 puck kernel: Socket destroy delayed (r=0 w=312)
Nov 21 20:50:39 puck kernel: TSW: win < 0 w=0 1=4004971059 2=4004971058
Nov 21 20:50:40 puck kernel: TSW: win < 0 w=0 1=4004971060 2=4004971059
Nov 21 20:50:40 puck kernel: TSW: win < 0 w=0 1=4004971061 2=4004971060
Nov 21 20:50:41 puck kernel: TSW: win < 0 w=0 1=4004971062 2=4004971061
Nov 21 20:50:42 puck kernel: TSW: win < 0 w=0 1=4004971063 2=4004971062

I don't know if these are related. I remember some discussion of the
"Socket destroy delayed" message a few versions back (I think in
1.3.x), and I know it isn't really an evil thing. The TSW thing, I
just don't know about.

Anyway, as before, comments, criticisms, flames, questions and gifts
are all welcome.

Nathan Spande

[debugging info follows]

The arpd debugging output:
Dst: (8aec2010)
Dev: c01d16a0 Stamp: 00000002 Updated: 0
HA: a0:00:00:00:05:00

Dst: (8aec2010)
Dev: c01d16a0 Stamp: 00000002 Updated: 0
HA: a0:00:00:00:05:00

Segmentation fault

The oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000040
current->tss.cr3 = 0079f000, *pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c014fe30>]
EFLAGS: 00010246
eax: c014fe20 ebx: c000cde0 ecx: 00000000 edx: c000ce00
esi: 00000008 edi: c000cdfc ebp: 00000008 esp: c07faf74
ds: 0018 es: 0018 ss: 0018
Process arpd.debug (pid: 204, process nr:
28, stackpage=c07fa000)
Stack: c000cde0 bffffb24 c01622a6 00000008 c000ce00 c04f1ebc c0bd9900 c04f1e88
ffffffea 0000001c c0124399 c04f1e88 c0bd9900 bffffb08 0000001c c0d6c810
00000004 08048588 bffffae0 c010a9d8 00000004 bffffb08 0000001c 00000004
Call Trace: [<c01622a6>] [<c0124399>] [<c010a9d8>]
Code: 83 7e 38 1c 74 1a 6a 01 56 e8 c2 c0 fe ff b8 ea ff ff ff 83

The ksymoops output:
puck:~$ ksymoops / < arpd.oops
Using `/' to map addresses to symbols.

>>EIP: c014fe30 <arpd_callback+10/e0>
Trace: c01622a6 <netlink_write+a6/d0>
Trace: c0124399 <sys_write+b9/f0>
Trace: c010a9d8 <system_call+38/40>

Code: c014fe30 <arpd_callback+10/e0> cmpl $0x1c,0x38(%esi)
Code: c014fe34 <arpd_callback+14/e0> je c014fe50
Code: c014fe36 <arpd_callback+16/e0> pushl $0x1
Code: c014fe38 <arpd_callback+18/e0> pushl %esi
Code: c014fe39 <arpd_callback+19/e0> call fffec0d0 <_EIP+fffec0d0>
Code: c014fe3e <arpd_callback+1e/e0> movl $0xffffffea,%eax
Code: c014fe43 <arpd_callback+23/e0> addl $0xffffff90,(%eax)
Code: c014fe46 <arpd_callback+26/e0> nop
Code: c014fe47 <arpd_callback+27/e0> nop