Got System Panic this am
-
@stephenw10
Oh - found this in msg buffer -<6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d7:76 to 3c:ec:ef:44:d0:c0 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c1 to 3c:ec:ef:44:d7:76 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d7:76 to 3c:ec:ef:44:d0:c0 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c1 to 3c:ec:ef:44:d7:76 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d7:76 to 3c:ec:ef:44:d0:c0 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c1 to 3c:ec:ef:44:d7:76 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d7:76 to 3c:ec:ef:44:d0:c0 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c1 to 3c:ec:ef:44:d7:76 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d7:76 to 3c:ec:ef:44:d0:c0 on ixl3.410 <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c1 to 3c:ec:ef:44:d7:76 on ixl3.410 <6>ovpn1: changing name to 'ovpns3' <6>arp: 192.168.1.15 moved from 3c:ec:ef:44:d0:c0 to 3c:ec:ef:44:d0:c1 on ixl3.410 <6>ovpns3: link state changed to UP kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d833cc stack pointer = 0x28:0xfffffe0075d5f1e0 frame pointer = 0x28:0xfffffe0075d5f200 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu1) trap number = 12 panic: page fault cpuid = 1 time = 1654268809 KDB: enter: panic
-
Hmm, the ARP movements are just log spam. You can stop logging it if you know what those devices are and they are in a lagg for example. It wouldn't cause a panic.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html
-
@stephenw10 Could it be related to the new OpenVPN DCO thing? I had made a changed to the tunnel (trying to debug a latency problem) when it panicked. It looks like the last thing was the tunnel enabling.
-
It was immediately afterwards? And you had DCO enabled?
It could well be related then. What snapshot is that and what hardware?
Steve
-
@stephenw10 22.05-BETA (amd64)
built on Tue May 31 06:20:27 UTC 2022
FreeBSD 12.3-STABLE -
@swixo
Oh yes - DCO on - the tunnel that came up just before the panic - is a DCO tunnel -
How many OpenVPN tunnels in total do you have there? How many are using DCO?
-
@stephenw10 Only this one is UP.
There are two others - but they were completely idle.
-
All 3 had DCO enabled though?
-
@stephenw10 Yes. They were enabled.
-
Mmm, OK. Is this the only time you have seen it?
-
@stephenw10 Yes - this is the first panic I have observed.
-
Ok, thanks. I've opened an internal bug for it. Our developers are looking into it.
Steve
-
@stephenw10 If helpful -
This system is the 'server' side of an s-s OpenVPN tunnel and it crashed.
The action that caused it was an update made to the remote client end. After that change - the tunnel went down, then up - then crashed.
-
@stephenw10 Will you let us know when a change is logged internally that should affect this? I dont want to try again until we have a resolution.
-
We can't know for certain since as far as I know you are the only person who had hit that. We never replicated it here. But we have applied a fix for what appears to be the bug that caused it. It's in 22.05-RC now.
Steve
-
@stephenw10 The latest snapshot says 22.09! - Is the fix available to me yet?
-
It is. If you don't see the branch
Next Stable Version (22.05
then first select the stable branch (22.01) and refresh. You should then see 22.05 offered as next which is 22.05-RC.Steve