I have had 2 kernel panics at shutdown, both related to trying to delete a network interface created by wireguard-go:
Normal procedure is (1) boot machine to console and login as user (2) xinit (3) open xterm window and:
(4) do work (5) close everything (6) shutdown xserver (7) issue shutdown command from console. This is when the kernel panic happens - if it panics at all.
It is very rare for me to explicitly close the wireguard interface.
This has only happened since switching to 12.0 and only happens occasionally.
Code:
Wed Dec 19 15:09:27 GMT 2018
FreeBSD zeeko 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
panic: page fault
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
<118>.
<118>Terminated
<118>Dec 19 15:08:17 zeeko syslogd: exiting on signal 15
<6>in_scrubprefix: err=65, prefix delete failed
<6><wireguard interface name>: deletion failed: 3
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0x28
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80de0ec3
stack pointer = 0x28:0xfffffe00a6e0e380
frame pointer = 0x28:0xfffffe00a6e0e3e0
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 = 1101 (wireguard-go)
trap number = 12
panic: page fault
cpuid = 3
time = 1545232097
KDB: stack backtrace:
#0 0xffffffff80be7977 at kdb_backtrace+0x67
#1 0xffffffff80b9b563 at vpanic+0x1a3
#2 0xffffffff80b9b3b3 at panic+0x43
#3 0xffffffff8107496f at trap_fatal+0x35f
#4 0xffffffff810749c9 at trap_pfault+0x49
#5 0xffffffff81073fee at trap+0x29e
#6 0xffffffff8104f1d5 at calltrap+0x8
#7 0xffffffff80de0e3e at in6_purgeaddr+0x46e
#8 0xffffffff80c9662f at if_purgeaddrs+0x21f
#9 0xffffffff80c97116 at if_detach_internal+0x916
#10 0xffffffff80c967ee at if_detach+0x2e
#11 0xffffffff80ca761f at tun_destroy+0xbf
#12 0xffffffff80c9f1e2 at if_clone_destroyif+0x1d2
#13 0xffffffff80c9efaa at if_clone_destroy+0x1ba
#14 0xffffffff80c9c002 at ifioctl+0x432
#15 0xffffffff80c04f3d at kern_ioctl+0x26d
#16 0xffffffff80c04c5e at sys_ioctl+0x15e
#17 0xffffffff81075449 at amd64_syscall+0x369
Uptime: 1h11m8sNormal procedure is (1) boot machine to console and login as user (2) xinit (3) open xterm window and:
Code:
sudo wg-quick up ~/wireguard_config/wg_interface1.conf(4) do work (5) close everything (6) shutdown xserver (7) issue shutdown command from console. This is when the kernel panic happens - if it panics at all.
It is very rare for me to explicitly close the wireguard interface.
This has only happened since switching to 12.0 and only happens occasionally.