unsheduled system reboot/crash
pfSense Community Edition 2.5.2
Try navigate to menu "Diagnostics" -> "Routes"
Then system crash/reboot, and after boot have text system dump (attached to report)
Updated by Jim Pingle about 1 year ago
- Status changed from New to Feedback
This is not a general problem but one specific to your install or environment.
The backtrace in both cases is identical:
db:0:kdb.enter.default> bt Tracing pid 39711 tid 100715 td 0xfffff801d0b5e740 kdb_enter() at kdb_enter+0x37/frame 0xfffffe006631f1c0 vpanic() at vpanic+0x197/frame 0xfffffe006631f210 panic() at panic+0x43/frame 0xfffffe006631f270 trap_fatal() at trap_fatal+0x391/frame 0xfffffe006631f2d0 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe006631f320 trap() at trap+0x286/frame 0xfffffe006631f430 calltrap() at calltrap+0x8/frame 0xfffffe006631f430 --- trap 0xc, rip = 0xffffffff80eebdf2, rsp = 0xfffffe006631f500, rbp = 0xfffffe006631f640 --- sysctl_dumpentry() at sysctl_dumpentry+0x1a2/frame 0xfffffe006631f640 rn_walktree() at rn_walktree+0x98/frame 0xfffffe006631f670 sysctl_rtsock() at sysctl_rtsock+0x20d/frame 0xfffffe006631f8a0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x8a/frame 0xfffffe006631f8e0 sysctl_root() at sysctl_root+0x220/frame 0xfffffe006631f960 userland_sysctl() at userland_sysctl+0x178/frame 0xfffffe006631fa10 sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe006631fac0 amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe006631fbf0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe006631fbf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80046ce2a, rsp = 0x7fffffffea38, rbp = 0x7fffffffea70 ---
In the past,
sysctl panics have sometimes been related to BIOS/hardware quirks and are not necessarily a software problem.
Since you seem to be able to repeat this, the first step is to move it up to a 2.6.0 development snapshot and see if the problem still happens there.
Updated by Mateusz Guzik about 1 year ago
I found the panicking instruction:
0xffffffff80eebdf2 <+418>: mov (%rcx),%rcx
info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr;
But given the panic if_addr is probably NULL.
That is, the route at hand is either in the process of being destroyed OR is not fully constructed yet and the code was unlucky enough to find it in this state.
A quick hack to work around the problem would NULL check the pointer, the correct fix will require finding out which of the cases we are dealing with here and plugging that.
I'm going to take a day or two with it and if I don't find any suspects I'll submit the workaround for the time being.