Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159815 - kernel panic when using QUEUE target with iptables
Summary: kernel panic when using QUEUE target with iptables
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Thomas Graf
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-08 09:33 UTC by Ilkka Pietikäinen
Modified: 2014-06-18 08:28 UTC (History)
4 users (show)

Fixed In Version: U4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-06-21 22:39:14 UTC
Target Upstream Version:

Attachments (Terms of Use)
Test program to recreate the issue. (deleted)
2005-07-15 19:07 UTC, Wendy Cheng
no flags Details

Description Ilkka Pietikäinen 2005-06-08 09:33:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Firefox/1.0.4

Description of problem:
When running our application, the kernel will give following panic (with kernel 2.6.9-5.EL):

Kernel panic - not syncing: net/ipv4/tcp_timer.c:211: spin_lock(net/ipv4/tcp_minisocks.c:e36dc0a0) already locked by net/ipv4/tcp_ipv4.c/1790

With SMP kernel (2.6.9-5.EL) the system hangs completely (will not take input from the console) and will not give any kernel panic message.

Our application uses QUEUE target with iptables to handle packet filtering in user space. It also uses TCP/UDP/multicast sockets and is quite CPU extensive. Our application is completely user space stuff.

This happens an all EL4 systems we have tried. Does not happen with EL3 or other 2.6.X kernel based distros we have tried.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start the application
2. After few minutes to few hours the system stops responding


Actual Results:  Kernel panic or system hangs completely

Expected Results:  System should stay responsive

Additional info:

Similar bug entered for FC3:

Comment 1 David Miller 2005-06-21 22:26:06 UTC
James, as author of the QUEUE iptables code could you take a quick
look at this one?  By far, the one constant is that everyone seeing
this bug is using QUEUE.

There also seems to be no indication that TUX is being used, but it
would be nice for the bug reporter to tell if they are in fact using
TUX as that adds yet another variable.

Comment 2 Ilkka Pietikäinen 2005-06-22 07:08:41 UTC
TUX is not used when this happens.

Comment 4 Wendy Cheng 2005-07-15 19:07:18 UTC
Created attachment 116818 [details]
Test program to recreate the issue.

Comment 5 James Morris 2005-07-24 05:46:58 UTC
(In reply to comment #1)

I gather it's this (patch upstream and also in url):

Comment 6 Ilkka Pietikäinen 2005-08-22 09:44:39 UTC
Is the patch (mentioned by James) included in any RH4 kernels?

Comment 7 James Morris 2005-08-22 09:53:40 UTC
It's in current RHEL4 kernel cvs, so it should be available in the U2 kernel to
be released very soon.

Comment 8 Ilkka Pietikäinen 2005-09-01 09:58:55 UTC
We have now done two days of testing with 2.6.9-11 kernel that is patched with
the given patch. The system is more stable but it has had panic three times with
the messege:

Kernel panic - not syncing: Fatal exception in interrupt

Part of the stack trace (handwritten so may contain some typos):


We are trying to collect more information using netdump utility. But if anybody
has any ideas, those are welcome.

Comment 9 Ilkka Pietikäinen 2005-09-07 07:35:28 UTC
I submitted a new bug about the case with the patched kernel

Comment 10 Ilkka Pietikäinen 2005-10-19 12:17:12 UTC
I just checked the 2.6.9-22 and I did not found the patch (I found the patch for
IPv6 though). Does anyone have information in which version this is included?

Comment 12 Linda Wang 2006-06-23 22:23:28 UTC
The issue you encountered may be fixed in U4 public beta kernel. 
Can you please give it a try, and post your results here? 

many thanks.

Note You need to log in before you can comment on or make changes to this bug.