Intermittent kernel panic after adding VLANs/IGMP proxy
-
In the last 2 weeks I've made some config changes to a very stable system running CE 2.6. The primary changes were adding a couple of VLANs, and while the previous config was also running an IGMP proxy, I had to make some changes to its settings. I mention this because I had some crashes that occured when applying the new IGMP config, unfortunately I don't have the dump files from those, as I thought I had figured it out and got the system back to a stable system.
In the last week I have had two kernel panic crashes. The most recent dump files are attached. I'm hoping someone can help me make sense of why these crashes are occurring.
As an aside, when these panics occur it locks up the system. I would prefer that the system reboot on kernel panic. kern.panic_reboot_wait_time is set to 10, I've also experimented with kern.powercycle_on_panic, but the machine doesn't power cycle or reboot. Are there other settings I need to be aware of?
It may be worth noting that the system ran fine between crashes, and both happened in the middle of the night under a very light load.
Thanks in advance,
Hans
-
Backtrace:
db:0:kdb.enter.default> show pcpu cpuid = 3 dynamic pcpu = 0xfffffe007e22b200 curthread = 0xfffff8002f3ed740: pid 75179 tid 100213 "netstat" curpcb = 0xfffff8002f3edce0 fpcurthread = 0xfffff8002f3ed740: pid 75179 "netstat" idlethread = 0xfffff80004237740: tid 100006 "idle: cpu3" curpmap = 0xfffff80138d90138 tssp = 0xffffffff837198d8 commontssp = 0xffffffff837198d8 rsp0 = 0xfffffe002c505bc0 kcr3 = 0x8000000143619677 ucr3 = 0x8000000104db6e77 scr3 = 0x104db6e77 gs32p = 0xffffffff837200f0 ldt = 0xffffffff83720130 tss = 0xffffffff83720120 tlb gen = 1887532 curvnet = 0 db:0:kdb.enter.default> bt Tracing pid 75179 tid 100213 td 0xfffff8002f3ed740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe002c5053f0 vpanic() at vpanic+0x197/frame 0xfffffe002c505440 panic() at panic+0x43/frame 0xfffffe002c5054a0 trap_fatal() at trap_fatal+0x391/frame 0xfffffe002c505500 trap() at trap+0x67/frame 0xfffffe002c505610 calltrap() at calltrap+0x8/frame 0xfffffe002c505610 --- trap 0x9, rip = 0xffffffff81208ef5, rsp = 0xfffffe002c5056e0, rbp = 0xfffffe002c505720 --- vm_reserv_extend() at vm_reserv_extend+0x65/frame 0xfffffe002c505720 vm_page_alloc_domain_after() at vm_page_alloc_domain_after+0xd3/frame 0xfffffe002c5057a0 vm_page_alloc() at vm_page_alloc+0x74/frame 0xfffffe002c505800 vm_fault() at vm_fault+0x5f8/frame 0xfffffe002c505950 vm_fault_trap() at vm_fault_trap+0x60/frame 0xfffffe002c505990 trap_pfault() at trap_pfault+0x19c/frame 0xfffffe002c5059e0 trap() at trap+0x410/frame 0xfffffe002c505af0 calltrap() at calltrap+0x8/frame 0xfffffe002c505af0 --- trap 0xc, rip = 0x8002877d7, rsp = 0x7fffffffe990, rbp = 0x7fffffffe990 ---Are the crashes always the same? Very little to go on there unfortunately. That looks like a memory issue but if it really is bad RAM the crashes would likely all be different.
Steve
-
Unfortunately I don't have the previous dump file, but according to my google search history it must have been different as I searched for ""Fatal trap 12: page fault while in kernel mode"".
Would that also point to a memory problem?
Hans
-
Possibly. We'd really need to see the backtrace at least.
-
I ran a lengthy memtest on it this afternoon and no errors, so I guess I will just have to wait and see if it repeats itself.
Is it the norm that pfSense does not reboot on a kernel panic?
-
No, I would usually expect it to reboot. However it can depend on how it panics.
