Kernel panic when routing large pings on an XScale (IXP425).

Hi,

I am using iptables on an Intel ixp425 (XScale/ARM processor) and am finding that I get a kernel panic when I try to send large (65k) pings to the board, or route them across the board. Iptables is not configured with any rules (see below) so all traffic is passed through the board. I don't see any problems with regular pings/FTP transfers/etc and I have left a chain of boards passing traffic over the weekend with no problems, however the board will always experience a kernel panic within 30 seconds of me initiating large pings. I have applied the ixp425_eth_1_1_update_nf_bridge.patch patch that I got from Intel (http://developer.intel.com/design/network/products/npfamily/ixp400_osc.htm) to no avail. I am running version 1.4 of Intel's software but before anyone suggests it upgrading to 1.5 is simply not an option at this point, unfortunately.

If I don't insert the iptables modules the board passes large pings without any problems so it is definitely a ixp425_eth.o/netfilter interaction problem. I've downloaded and searched through the archives for this board and have found a posting from Rob Ranslam of Intel stating that if I also have ebtables then I'll need an extra patch from sourceforge, however I *don't* have ebtables so I can't see how that patch would be needed in my case. The documentation for the Intel patch seems to relate to bridging, and I've seen posts from others who say routing works but bridging doesn't but my problem definitely relates to routing. Has anyone seen a problem like this and/or can anyone offer any ideas as to where I should be looking for the problem as I'm a netfilter newbie? Thanks.

Slan,
Cian

PS: Below is the output of iptables --list for reference;

 root@(none):~# iptables 
--list                                                 
 Chain INPUT (policy 
ACCEPT)                                                    
 target     prot opt source               
destination                           

Chain FORWARD (policy
ACCEPT)
target prot opt source
destination

Chain OUTPUT (policy
ACCEPT)
target prot opt source
destination
root@(none):~#

I experienced a similar problem when I was doing some IPSEC stuff with IPTABLES under RHEL 4. There was an issue with a TCP packet being locked by the system and in a chain and under a certain case it would attempt to lock it again. Not sure of the complete details though.

Anyways, after talking with some people about my problem it had to do with locking of the chain before passing it around through other chains for IPSEC where it had to traverse the same table again. It sounds similar to my problem. Here is the link to the RedHat bug I submitted (and was closed) some time ago.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154347

It does require a kernel recompile as it's a kernel bug.

Hope this helps.

Gary Smith

I experience the very same error just yesterday:
KERNEL PANIC - Not Syncing: net/ipv4/xfrm4_output.c:106 : spin_lock (net/xfrm/xfrm_state.C : ddd2b014) already locked by net/ipv4/xfrm4_output.c/106

on a Fedora Core2 box running 2.6.10-1.771_FC2 kernel and ipsec-tools-0.5-2.fc2.

the curiosity is that this box was running ok for more than a month with this policies:

spdadd 10.3.1.0/24 10.3.4.0/24 any -P in ipsec

           esp/tunnel/CENTER_IP-MY_IP/require;

spdadd 10.3.4.0/24 10.3.1.0/24 any -P out ipsec

           esp/tunnel/MY_IP-CENTER_IP/require;

and start to trouble when changed to :

spdadd 10.0.0.0/8 10.3.4.0/24 any -P in ipsec

           esp/tunnel/CENTER_IP-MY_IP/require;

spdadd 10.3.4.0/24 10.0.0.0/8 any -P out ipsec

           esp/tunnel/MY_IP-CENTER_IP/require;

LALO

Este e-mail y cualquier posible archivo adjunto está dirigido únicamente al destinatario del mensaje y contiene información que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier utilización, difusión o copia de este e-mail por cualquier persona o entidad que no sean las específicas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicación que haya sido emitida incumpliendo nuestra Política de Seguridad de la Información. . . . . . . . . .
This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender inmediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that not is the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.