[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