Got System Panic this am
-
The actual backtrace to the panic is the important part there.
I'm not familiar with that though.
Is there anything in the message buffer leading up to that? Any errors?
What snapshot was that? What hardware is it running on?
Steve
-
@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