Like others, I have been suffering with a problem since December 1999
when I switched from 2.0.35 kernel +ax25 to the new 2.2.13, 2.2.14 to
the current 2.2.15.
The problem I have is with the Ax25 code. (maybe nothing wrong with the
code - I still have a problem to solve)
The AX25 interface(s) normally one of the very busy ax25 interfaces.
(they all run TCP/IP,AX25,NetROm over them) stop working decoding for
AX25 data, yet the TCP/IP stack continues to work over the interface.
It will run for an hour or up to four days before condition arises.
Only fix I have found is to reboot the system.
I have in the past two months commented on the kiss protocol error
messages. Any real time changes to kiss params causes protocol errors.
Doing a netstat -a or netstat -F ax25, netstat --ax25 normally comes
up with a segmentation error on trying to display the ax25 information
when the CONDITION occurs .
Having seen Bent's OZ6BL comments re PCi, got me to check the 2.0.35
hard disk and I had the PCI disabled. My 486DX/66 motherboard does have
PCI. Though I now remember years ago that to use PCI under windows 3.11
I needed to install a driver.
Over night I recompiled the linux kernel with the PCI option disabled.
rebooted on the new kernel. after an hour issued the netstat command.
This is what I get at the end of a netstat -a command
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
Segmentation fault
Issuing command to list ax25 details
# netstat --ax25
Active AX.25 sockets
Dest Source Device State Vr/Vs Send-Q Recv-Q
Segmentation fault
associated software installed :-
Slakware 7.0
Kernel 2.2.15
ax25-tools-0.0.6
ax25-apps-0.0.4
node-0.3.0
libax25-0.0.7
node-0.3.0
http-1.22
xd7.01m
PC = 486dx/66
Has anyone else experience this. Or have any more idea's I can follow
up.
As part of investigation over the past six months, I have moved, swapped
the serial interfaces about (seven of them all running on their own
IRQ's as it was for 12 months on the 2.0.35 series of kernels.) Disabled
facilities to try and move the problem.
Also looked at timers, as one thought was that orphaned ax25/netrom
network connections are not clearing down. I still like this idea,
though finding it hard to prove this theory.
de Paul g4apl Sysop gb7cip.ampr.org
In message <[EMAIL PROTECTED]>,
Bent Bagger <[EMAIL PROTECTED]> writes
>For what it is worth: I had similar, but not quite identical, oops' from
>2.2.13 and 2.2.14 kernels. It turned out that I had errorneously
>misconfigured the kernel. The machine is a 33 MHz 486 with standard AT
>expansion boards. The misconfiguration consisted in my enabling the PCI bus
>code in the kernel. When I changed the kernel configuration and rebuilt the
>kernel, not only disappeared the kernel oops but the machine appeared to be
>twice as fast.
>
>Best 73 de Bent/OZ6BL
>
--
[EMAIL PROTECTED]
