From: Matt Ayres <matta@tektonic.net>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Patrick McHardy <kaber@trash.net>,
James Morris <jmorris@namei.org>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Netfilter Development Mailinglist
<netfilter-devel@lists.netfilter.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Re: Panic in ipt_do_table with 2.6.16.13-xen
Date: Tue, 23 May 2006 08:03:21 -0400 [thread overview]
Message-ID: <4472FA09.1010800@tektonic.net> (raw)
In-Reply-To: <fb268aac0218b2a558e922858f99b20b@cl.cam.ac.uk>
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.
Thanks,
Matt Ayres
next prev parent reply other threads:[~2006-05-23 12:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-15 17:46 Panic in ipt_do_table with 2.6.16.13-xen Matt Ayres
2006-05-15 19:27 ` Patrick McHardy
2006-05-16 0:01 ` Matt Ayres
2006-05-16 3:31 ` James Morris
2006-05-16 13:49 ` [Xen-devel] " Matt Ayres
2006-05-16 15:28 ` James Morris
2006-05-18 23:58 ` Matt Ayres
2006-05-19 0:05 ` James Morris
2006-05-19 0:16 ` Matt Ayres
2006-05-19 0:45 ` Matt Ayres
2006-05-21 17:43 ` Patrick McHardy
2006-05-22 14:31 ` Matt Ayres
2006-05-22 14:42 ` Keir Fraser
2006-05-22 14:43 ` Patrick McHardy
2006-05-23 9:54 ` Keir Fraser
2006-05-23 12:03 ` Matt Ayres [this message]
2006-05-23 21:15 ` Keir Fraser
2006-05-23 21:23 ` Matt Ayres
2006-05-23 21:27 ` Keir Fraser
2006-05-24 7:16 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4472FA09.1010800@tektonic.net \
--to=matta@tektonic.net \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox