WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: Panic in ipt_do_table with 2.6.16.13-xen
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 23 May 2006 10:54:35 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Netfilter Development Mailinglist <netfilter-devel@xxxxxxxxxxxxxxxxxxx>, James Morris <jmorris@xxxxxxxxx>, Matt Ayres <matta@xxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 23 May 2006 02:54:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4471CE19.5070802@xxxxxxxxx>
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>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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.

 Thanks,
 Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel