[HEADS UP] merging projects/pf into head
Ian FREISLICH
ianf at clue.co.za
Wed Sep 12 11:00:57 UTC 2012
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
More information about the freebsd-pf
mailing list