Date: Wed, 12 Sep 2012 13:00:52 +0200 From: Ian FREISLICH <ianf@clue.co.za> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: pf@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head Message-ID: <E1TBkge-0001e1-2y@clue.co.za> In-Reply-To: <20120912104949.GC84189@glebius.int.ru> References: <20120912104949.GC84189@glebius.int.ru> <20120905115140.GF15915@FreeBSD.org> <E1TBkOI-0001Zg-IE@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1TBkge-0001e1-2y>