Hi
One of my machines running kernel 2.4.18 is getting kernel panics intermittently (30minutes to 4/5 hours).
from the logs I believe is the culprit:
kernel: LIST_DELETE: ip_conntrack_core.c:165 `&ct->tuplehash[IP_CT_DIR_REPLY]'(c6c78e44) not in &ip_conntrack_hash [hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple)].
After searching google for a while i noticed this was the exact error for problems with the 2.4.10 kernel and apparently have been fixed. Here is the link:
http://lists.netfilter.org/pipermail/netfilter-announce/2002/000010.html
If you need any additional information let me know. Here /proc/version for the moment:
Linux version 2.4.18 (root@roadkill) (gcc version 2.96 20000731 (Red Hat Linux 7.0)) #1 SMP Mon Jun 17 18:06:40 SAST 2002
Hopefully someone can help me resolve this issue.
Thanks
Merritt
On Mon, Sep 02, 2002 at 10:21:56AM +0200, [email protected] wrote:
> One of my machines running kernel 2.4.18 is getting kernel panics
intermittently (30minutes to 4/5 hours).
> from the logs I believe is the culprit:
> kernel: LIST_DELETE: ip_conntrack_core.c:165
`&ct->tuplehash[IP_CT_DIR_REPLY]'(c6c78e44) not in &ip_conntrack_hash
[hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple)].
i've wrestled quite a bit with this problem, but never really could
figure out the correct answers. some people blamed the compiler, but
different versions of the compiler still produced it.
i saw it in 2.4.18 and 2.4.19pre kernels on my dual athlon.
in the end i found switching from snat to masqerading for my internal
network seemed to eliminate it. also i found that if i eliminated my
udp outgoing remote log stream from syslog-ng, i could keep the snat
and have the box still live.
i'm now running nicely with 2.4.19, snat firewall rules, and no remote
logging.
--
____________________}John Flinchbaugh{______________________
| [email protected] http://www.hjsoft.com/~glynis/ |
~~Powered by Linux: Reboots are for hardware upgrades only~~
On Mon, 2 Sep 2002 10:21:56 +0200
[email protected] wrote:
> Hi
>
> One of my machines running kernel 2.4.18 is getting kernel panics intermittently (30minutes to 4/5 hours).
>
> from the logs I believe is the culprit:
>
> kernel: LIST_DELETE: ip_conntrack_core.c:165 `&ct->tuplehash[IP_CT_DIR_REPLY]'(c6c78e44) not in &ip_conntrack_hash [hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple)].
This problem has been plaguing us for a while. You're using gcc 2.96, which is interesting.
What connection tracking/NAT modules have you got? What kind of traffic are
you getting? (eg. are you getting IRC traffic? FTP traffic?).
I really want to chase this down, but I've yet to find the cause.
Rusty.
--
there are those who do and those who hang on and you don't see too
many doers quoting their contemporaries. -- Larry McVoy
> On Mon, 2 Sep 2002 10:21:56 +0200
> >
> > One of my machines running kernel 2.4.18 is getting kernel panics intermittently (30minutes to 4/5 hours).
> >
> > from the logs I believe is the culprit:
> >
> > kernel: LIST_DELETE: ip_conntrack_core.c:165 `&ct->tuplehash[IP_CT_DIR_REPLY]'(c6c78e44) not in &ip_conntrack_hash [hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple)].
>
> This problem has been plaguing us for a while. You're using gcc 2.96, which is interesting.
>
> What connection tracking/NAT modules have you got?
ipt_LOG ipt_limit ipt_state iptable_filter ipt_MASQUERADE iptable_nat
> What kind of traffic are you getting? (eg. are you getting IRC traffic? FTP traffic?).
There is nothing really to hectic that is using NAT as most of the traffic goes via a proxy. I'd say the only things that use NAT would be services that dont support an http proxy, kazaa,edonkey,SMTP,pop.
The following ports are NAT'ed 25 22 80 (not really used) 9034 59651 4661 4662
This is the NAT part the gateway config:
$IPTABLES -t nat -A POSTROUTING -o $WAN -j MASQUERADE
$IPTABLES -A FORWARD -i $LAN -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
Traffic is pretty low in general. If there is any other information i can give you please let me know.
Regards
Merritt
>
> I really want to chase this down, but I've yet to find the cause.
>
> Rusty.
> --
> there are those who do and those who hang on and you don't see too
> many doers quoting their contemporaries. -- Larry McVoy
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/