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

[Xen-devel] iptables causing kernel panic - part II

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] iptables causing kernel panic - part II
From: Matt Ayres <matta@xxxxxxxxxxxx>
Date: Mon, 15 May 2006 11:35:39 -0400
Delivery-date: Mon, 15 May 2006 08:36:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.2 (Windows/20060308)
Hi,

I am seeing the following panic's from the latest 3.0-testing. SCTP is disabled entirely and the only bugfix patches beyond 2.6.16.13 affect SCTP for the most part.

Here is my trace, I was not able to get the Code line unfortunately so I don't have specific line numbers. I'd like re-confirmation this is not specific to Xen. If it is not I will be sending this over to LKML.

Panic:

Unable to handle kernel paging request at virtual addr
c03d96a9
06099000 -> *pde = 00000001:a75cb001
005a0000 -> *pme = 00000000:eb2f0067
0faf0000 -> *pte = 00000000:00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0061:[<c03d96a9>]    Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286   (2.6.16.13-xen #1)
eax: 00000002   ebx: c8635020   ecx: c8635020   edx: 00000000
esi: d143a000   edi: 00000000   ebp: d143e560   esp: c0517d8c
ds: 007b   es: 007b   ss: 0069
Stack: <0>c04d056c 00000000 c8635020 00000000 cf4a8000 c96e2800 d143a000 0000000
00000001 00000000 c0517e2c 80000000 c03acc04 c96e2800 c03da724 c0517e70
00000002 cf4a8000 c96e2800 c04d0540 00000000 c03a2e50 00000002 c0517e70
Call Trace:
[<c03acc04>] ip_forward_finish+0x0/0x36
[<c03da724>] ipt_hook+0x1c/0x20
[<c03a2e50>] nf_iterate+0x2c/0x5e
[<c03acc04>] ip_forward_finish+0x0/0x36
[<c03acc04>] ip_forward_finish+0x0/0x36
[<c03a2f4b>] nf_hook_slow+0x3c/0xc3
[<c03acc04>] ip_forward_finish+0x0/0x36
[<c03acdd8>] ip_forward+0x19e/0x22e
[<c03acc04>] ip_forward_finish+0x0/0x36
[<c03abcf7>] ip_rcv+0x40e/0x48f
[<c037dcb5>] netif_receive_skb+0x255/0x294
[<c02e82e6>] tg3_poll+0x532/0x76c
[<c037bd82>] net_rx_action+0xaa/0x17c

ksymoops output:

>>EIP; c03d96a9 <ipt_do_table+ad/2d0>   <=====

>>esp; c0517d8c <init_thread_union+1d8c/2000>

Trace; c03acc04 <ip_forward_finish+0/36>
Trace; c03da724 <ipt_hook+1c/20>
Trace; c03a2e50 <nf_iterate+2c/5e>
Trace; c03acc04 <ip_forward_finish+0/36>
Trace; c03acc04 <ip_forward_finish+0/36>
Trace; c03a2f4b <nf_hook_slow+3c/c3>
Trace; c03acc04 <ip_forward_finish+0/36>
Trace; c03acdd8 <ip_forward+19e/22e>
Trace; c03acc04 <ip_forward_finish+0/36>
Trace; c03abcf7 <ip_rcv+40e/48f>
Trace; c037dcb5 <netif_receive_skb+255/294>
Trace; c02e82e6 <tg3_poll+532/76c>
Trace; c037bd82 <net_rx_action+aa/17c>


Question on this, swapper seems to be the "process" the majority of the time. Could this be from netfilter conntrack being overallocated for the RAM available to dom0 and since netfilter can't be swapped out it causes a panic... or should the kernel just "know" this and swap out the apps.

Thank you,
Matt Ayres

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

<Prev in Thread] Current Thread [Next in Thread>