This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: Panic in ipt_do_table with

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Panic in ipt_do_table with
From: Matt Ayres <matta@xxxxxxxxxxxx>
Date: Tue, 23 May 2006 08:03:21 -0400
Cc: Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>, Patrick McHardy <kaber@xxxxxxxxx>, James Morris <jmorris@xxxxxxxxx>
Delivery-date: Tue, 23 May 2006 05:05:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <fb268aac0218b2a558e922858f99b20b@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: TekTonic
References: <4468BE70.7030802@xxxxxxxxxxxx> <4468D613.20309@xxxxxxxxx> <44691669.4080903@xxxxxxxxxxxx> <Pine.LNX.4.64.0605152331140.10964@xxxxxxx> <4469D84F.8080709@xxxxxxxxxxxx> <Pine.LNX.4.64.0605161127030.16379@xxxxxxx> <446D0A0D.5090608@xxxxxxxxxxxx> <Pine.LNX.4.64.0605182002330.6528@xxxxxxx> <446D0E6D.2080600@xxxxxxxxxxxx> <446D151D.6030307@xxxxxxxxxxxx> <4470A6CD.5010501@xxxxxxxxx> <4471CB54.401@xxxxxxxxxxxx> <4471CE19.5070802@xxxxxxxxx> <fb268aac0218b2a558e922858f99b20b@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20060308)
Keir Fraser wrote:

On 22 May 2006, at 15:43, Patrick McHardy wrote:

The only other thing I can imagine is that something is wrong with
the per-CPU copy of the ruleset, i.e. either smp_processor_id is
returning garbage or for_each_possible_cpu misses a CPU during
initialization. I have no idea if Xen really does touch this code,
but other than that I don't really see what it could break.

Of the options you consider, this sounds most likely. Really we need some more info from a crash: I'd like to get disassembly from a vmlinux image if that's possible, Matt.

I have an un-stripped vmlinux built with kernel debugging and the corresponding System.map. I will be sending these to you privately shortly. You can see the multiple traces sent to this list.

It appears having the bandwidth accounting being performed by count rules in the FORWARD chain is causing it for my setup. I suppose I could optimize this to make the kernel spend as little time in ipt_do_table in regards to the FORWARD chain. I flushed the FORWARD chain (normally 100-120 rules) and have not experienced any crashes so far... disabling bandwidth monitoring is by no means a long term fix.

It might be more generic in the symptoms, perhaps just any chain with many rules and lots of traffic or It's just the FORWARD one that seems to be doing it for me as that is where ipt_do_table spends most of it's time.

Matt Ayres

Xen-devel mailing list