Messages in this thread | | | Date | Tue, 26 Nov 1996 18:13:11 -0600 | From | Nathan Spande <> | Subject | arpd problems |
| |
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 nspande@gac.edu
[debugging info follows]
The arpd debugging output: /sbin/arpd.debug Type: LOOKUP Dst: 138.236.32.16 (8aec2010) Dev: c01d16a0 Stamp: 00000002 Updated: 0 HA: a0:00:00:00:05:00
Type: REPLY Dst: 138.236.32.16 (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 /System.map < arpd.oops Using `/System.map' 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 <arpd_callback+30/e0> 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
| |