Hi,
I am currently dealing with an annoying kernel panic on a Deciso DEC750.
Situation:
- Device was used for 12+ months behind a router "Digitalisierungsbox Premium 2", provided on a fiber business account by Deutsche Telekom - static IPv4 address and static /56 net + /64 address included. The router provided RFC1918 IPv4 addresses and NAT and set the Decisio Box as "exposed". Worked OK. (up to latest release of the 25.1 branch). Since the business router wouldn't provide DHCPv6 PD we decided to change the setup.
- The "Digitalisierungsbox" came with a plugged in "Digitalisierungsbox Smart 2" (aka Zyxel's GPON SFP module) which was then plugged in directly to the DEC750 on X0. After configuring PPPoE as usual the connection was established and work perfectly on IPv4 and IPv6, tracking the WAN for IPv6 subnets worked on all local VLANs. Firewall rules were extended to IPv6 and that's how it worked again, no problems detected.
- The OPNsense box also provides OpenVPN and IPv6 was working here as well. This includes OpenVPN access via IPv6 as well as handing out IPv6 addresses on OpenVPN.
- After a couple of days the box restarted itself after a kernel panic and repeated to do so every 2-7 days. Trying to trigger a panic by heavy load on traffic and/or OpenVPN was not successful. There is no indication on when the restart happens. Upgraded from the latest 25.1 to 25.7.3_7-amd64 and still it takes a couple of days for the next kernel panic to occur.
- Based on https://forum.opnsense.org/index.php?topic=41808.15 we tried disabling IPv6 on WAN and removed it from all VLANs and OpenVPN. And now the box runs smoothly as usual for at least 10 days now. No further kernel panic so far.
- The stack trace is like this:
panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe003c242000
cpuid = 3
time = 1757468281
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00aa80c780
vpanic() at vpanic+0x131/frame 0xfffffe00aa80c8b0
panic() at panic+0x43/frame 0xfffffe00aa80c910
vm_fault() at vm_fault+0x15af/frame 0xfffffe00aa80ca30
vm_fault_trap() at vm_fault_trap+0x81/frame 0xfffffe00aa80ca80
trap_pfault() at trap_pfault+0x1be/frame 0xfffffe00aa80cad0
calltrap() at calltrap+0x8/frame 0xfffffe00aa80cad0
--- trap 0xc, rip = 0xffffffff80f7ec41, rsp = 0xfffffe00aa80cba0, rbp = 0xfffffe00aa80cbb0 ---
vm_radix_remove() at vm_radix_remove+0x51/frame 0xfffffe00aa80cbb0
vm_page_object_remove() at vm_page_object_remove+0x69/frame 0xfffffe00aa80cbd0
vm_page_free_prep() at vm_page_free_prep+0x24/frame 0xfffffe00aa80cbf0
vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfffffe00aa80cc20
vm_object_page_remove() at vm_object_page_remove+0x6a/frame 0xfffffe00aa80cc80
vm_map_entry_delete() at vm_map_entry_delete+0xf5/frame 0xfffffe00aa80ccc0
vm_map_delete() at vm_map_delete+0x7b/frame 0xfffffe00aa80cd30
vm_map_remove() at vm_map_remove+0x96/frame 0xfffffe00aa80cd60
vmspace_exit() at vmspace_exit+0xab/frame 0xfffffe00aa80cd90
exit1() at exit1+0x53a/frame 0xfffffe00aa80cdf0
sys_exit() at sys_exit+0xd/frame 0xfffffe00aa80ce00
amd64_syscall() at amd64_syscall+0x10e/frame 0xfffffe00aa80cf30
- The failure mode suggests some memory corruption that does not immediately show itself but causes a delayed kernel panic. So other than "switching off IPv6" I have no idea how to proceed right now. I checked system.log and did not find anything helpful or interesting other than a signal 11 on a python process
...
(repeating for some days until the crash)
2025-09-21T23:17:05 Notice dhcp6c dhcp6c_script: RENEW on pppoe0 executing
2025-09-21T23:02:05 Notice dhcp6c dhcp6c_script: RENEW on pppoe0 executing
2025-09-21T22:51:00 Notice kernel <6>[449403] pid 85765 (python3.11), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
2025-09-21T22:47:05 Notice dhcp6c dhcp6c_script: RENEW on pppoe0 executing
2025-09-21T22:32:05 Notice dhcp6c dhcp6c_script: RENEW on pppoe0 executing
...
My questions:
- Is there anything I can do to locate the problem and may work around it? I would really like to write a bug report but just having a kernel panic in a page handler is not really helpful I guess.
- Can I do something about the DEC750, I am not an expert on this piece of hardware and it's properties and/or quirks (if any).
- Does anybody else have issues with that kind of setup and IPv6 and possibly a workaround?