From owner-freebsd-pf@FreeBSD.ORG Wed Sep 12 11:00:57 2012 Return-Path: Delivered-To: pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC83D106566B; Wed, 12 Sep 2012 11:00:56 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from zcs04.jnb1.cloudseed.co.za (zcs04.jnb1.cloudseed.co.za [41.154.0.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8268FC16; Wed, 12 Sep 2012 11:00:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTP id D36C12A82A8C; Wed, 12 Sep 2012 13:00:54 +0200 (SAST) X-Virus-Scanned: amavisd-new at zcs04.jnb1.cloudseed.co.za Received: from zcs04.jnb1.cloudseed.co.za ([127.0.0.1]) by localhost (zcs04.jnb1.cloudseed.co.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWaFI-kARiaK; Wed, 12 Sep 2012 13:00:54 +0200 (SAST) Received: from clue.co.za (l2tp.clue.co.za [41.154.88.20]) by zcs04.jnb1.cloudseed.co.za (Postfix) with ESMTPSA id 0ADE62A829F5; Wed, 12 Sep 2012 13:00:54 +0200 (SAST) Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TBkge-0001e1-2y; Wed, 12 Sep 2012 13:00:52 +0200 To: Gleb Smirnoff From: Ian FREISLICH In-Reply-To: <20120912104949.GC84189@glebius.int.ru> References: <20120912104949.GC84189@glebius.int.ru> <20120905115140.GF15915@FreeBSD.org> X-Attribution: BOFH Date: Wed, 12 Sep 2012 13:00:52 +0200 Message-Id: Cc: pf@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 11:00:57 -0000 Gleb Smirnoff wrote: > I> Fatal trap 12: page fault while in kernel mode > I> cpuid = 9; apic id = 09 > I> fault virtual address = 0x28 > I> fault code = supervisor read data, page not present > I> instruction pointer = 0x20:0xffffffff802d9ff1 > I> stack pointer = 0x28:0xffffff84626540b0 > I> frame pointer = 0x28:0xffffff8462654110 > I> code segment = base 0x0, limit 0xfffff, type 0x1b > I> = DPL 0, pres 1, long 1, def32 0, gran 1 > I> processor eflags = interrupt enabled, resume, IOPL = 0 > I> current process = 11 (irq257: bce1) > I> trap number = 12 > I> panic: page fault > I> cpuid = 9 > I> KDB: stack backtrace: > I> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > I> panic() at panic+0x1ce > I> trap_fatal() at trap_fatal+0x290 > I> trap_pfault() at trap_pfault+0x210 > I> trap() at trap+0x2b4 > I> calltrap() at calltrap+0x8 > I> --- trap 0xc, rip = 0xffffffff802d9ff1, rsp = 0xffffff84626540b0, rbp = 0x ffffff > I> 8462654110 --- > I> pf_anchor_node_RB_NEXT() at pf_anchor_node_RB_NEXT+0x1 > I> pf_test_rule() at pf_test_rule+0x4d7 > I> pf_test() at pf_test+0x2b28 > I> pf_check_in() at pf_check_in+0x26 > I> pfil_run_hooks() at pfil_run_hooks+0x9e > I> ip_fastforward() at ip_fastforward+0x1b9 > I> ether_demux() at ether_demux+0x17e > I> ether_nh_input() at ether_nh_input+0x24b > I> netisr_dispatch_src() at netisr_dispatch_src+0x212 > I> ether_demux() at ether_demux+0x6c > I> ether_nh_input() at ether_nh_input+0x24b > I> netisr_dispatch_src() at netisr_dispatch_src+0x212 > I> bce_intr() at bce_intr+0x47a > > Panicing in the ruleset parsing is strange. Do you have modifications to the > ruleset at run time? We do occasionally make changes to the ruleset at runtime, however no changes were made to the ruleset since boot. If this trace indicates a panic in ruleset parsing then possibly even this stack trace is corrupted. > I> The crashdump is useless however: > > Strange that dump is bad. Is pf compiled into kernel or loaded? I don't think these servers have produced a useful crashdump since 2009. > However, try to look at traces of other threads in this dump. I'll have to compile a new kernel which drops into the kernel debugger. But I'm not sure how to inspect the other threads. Should I try running with the netisr defaults and without fastforwarding? Ian -- Ian Freislich