Actions
Bug #5428
closedFrequent IPv6 panic on 2.3 - May be log-related
Start date:
11/12/2015
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3
Affected Architecture:
amd64
Description
Hit a panic on 2.3 twice now, ping me for the full trace.
Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ba8a8b stack pointer = 0x28:0xfffffe003f3d3f40 frame pointer = 0x28:0xfffffe003f3d3f50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: igb0:que 0) [ thread pid 12 tid 100028 ]
db:0:kdb.enter.default> show pcpu cpuid = 0 dynamic pcpu = 0x502400 curthread = 0xfffff800034c9940: pid 12 "irq256: igb0:que 0" curpcb = 0xfffffe003f3d4cc0 fpcurthread = none idlethread = 0xfffff80003290000: tid 100003 "idle: cpu0" curpmap = 0xffffffff822b4928 tssp = 0xffffffff822cf790 commontssp = 0xffffffff822cf790 rsp0 = 0xfffffe003f3d4cc0 gs32p = 0xffffffff822d11e8 ldt = 0xffffffff822d1228 tss = 0xffffffff822d1218 db:0:kdb.enter.default> bt Tracing pid 12 tid 100028 td 0xfffff800034c9940 strlen() at strlen+0xb/frame 0xfffffe003f3d3f50 kvprintf() at kvprintf+0xf9c/frame 0xfffffe003f3d4060 _vprintf() at _vprintf+0x8d/frame 0xfffffe003f3d4140 log() at log+0x5c/frame 0xfffffe003f3d41a0 ip6_forward() at ip6_forward+0x119/frame 0xfffffe003f3d42f0 pf_refragment6() at pf_refragment6+0x16e/frame 0xfffffe003f3d43b0 pf_test6() at pf_test6+0x1448/frame 0xfffffe003f3d46e0 pf_check6_out() at pf_check6_out+0x1d/frame 0xfffffe003f3d4700 pfil_run_hooks() at pfil_run_hooks+0x8d/frame 0xfffffe003f3d4790 bridge_pfil() at bridge_pfil+0x25b/frame 0xfffffe003f3d4810 bridge_broadcast() at bridge_broadcast+0x22c/frame 0xfffffe003f3d4880 bridge_forward() at bridge_forward+0x245/frame 0xfffffe003f3d48e0 bridge_input() at bridge_input+0x2a0/frame 0xfffffe003f3d4950 ether_nh_input() at ether_nh_input+0x2a5/frame 0xfffffe003f3d49b0 netisr_dispatch_src() at netisr_dispatch_src+0x62/frame 0xfffffe003f3d4a20 igb_rxeof() at igb_rxeof+0x63b/frame 0xfffffe003f3d4ad0 igb_msix_que() at igb_msix_que+0x16d/frame 0xfffffe003f3d4b20 intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame 0xfffffe003f3d4b60 ithread_loop() at ithread_loop+0x96/frame 0xfffffe003f3d4bb0 fork_exit() at fork_exit+0x9a/frame 0xfffffe003f3d4bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe003f3d4bf0 --- trap 0, rip = 0, rsp = 0xfffffe003f3d4cb0, rbp = 0 ---
I may have a means to reproduce it, but as it is my prod edge firewall I'm not too keen on testing that theory frequently.
Luiz said "I'll take a look, seems that something is wrong with log (a possible null string is passed to strlen)"
Actions