A kernel panic at shutdown is possible if a GBDE-encrypted swap
partition is in use (i.e., swapinfo shows pages used under the "Used"
column). I don't know if a minimum percentage of swap needs to be in
use to provoke the panic. I have /tmp mounted as a md-backed
filesystem on GBDE-encrypted swap, so usually I have at least a couple
of tens of megabytes of swap used by the time I shutdown. In my case,
I always get a panic (unless no swapping has occurred).
Here is the panic I got when I last did a shutdown on my system:
All buffers synced.
unmount of /dev failed (BUSY)
GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed.
GEOM_MIRROR: Device raid1 destroyed.
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04eed94
stack pointer = 0x28:0xd56c2c5c
frame pointer = 0x28:0xd56c2c60
code segment = base rx0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 79 (g_bde mirror/raid1b)
[thread pid 79 tid 100042 ]
Stopped at turnstile_setowner+0xb: movl 0x74(%edx),%eax
Tracing pid 79 tid 100042 td 0xc1a2f480
turnstile_setowner(ad89d,c06601a0,0,c1bab02c,c1bab02c) at turnstile_setowner+0xb
turnstile_wait(c1bab02c,0,23,c1a2f480,d56c2cd0) at turnstile_wait+0xb9
_mtx_lock_sleep(c1bab02c,c1a2f480,0,0,0) at _mtx_lock_sleep+0x87
msleep(c1bab000,c1bab02c,4c,c0608dee,3e8,1,c0609225) at msleep+0x380
g_bde_worker(c1be4b00,d56c2d38,c1be4b00,c1be4b00,c04947a0) at g_bde_worker+0x299
fork_exit(c04947a0,c1be4b00,d56c2d38) at fork_exit+0x6b
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd56c2d6c, ebp = 0 ---
I have marked this PR as "serious" only because it prevents a remote
shutdown/reboot from succeeding.
Enable GBDE-encrypted swap (e.g. add 'gbde_swap_enable="YES"' to
/etc/rc.conf) and do a lot of swapping; then execute "shutdown -r now".
Over to maintainer(s).
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped