Was tinkering on a bt(5) script for trying to debug an issue in vmm(4)
when I managed to start hitting a panic "wakeup: p_stat is 2" being
triggered by kqueue coming from the softnet kernel task.
I'm running an amd64 kernel built from the tree today (latest CVS commit
id UynQo1r7kLKA0Q2p) with VMM_DEBUG option set and the defaults from
GENERIC.MP. Userland is from the latest amd snap.
To reproduce, I'm running a single OpenBSD-current guest under vmd(8)
which I'm targeting with the following trivial btrace script I was
working on to use for debugging something in vmm(4):
tracepoint:sched:sleep / pid == $1 && tid == $2 /{
printf("pid %d, tid %d slept %d!\n", pid, tid, nsecs);
}
tracepoint:sched:wakeup / pid == $1 && tid == $2 /{
printf("pid %d, tid %d awoke %d!\n", pid, tid, nsecs);
}
Both times this happened I was trying to sysupgrade the vmd(8) guest
while running the above btrace script. When I don't run the script,
there is no panic.
Image of the full backtrace is here: https://imgur.com/a/swW1qoj
Simple transcript of the call stack after the panic() call looks like:
wakeup_n
kqueue_wakeup
knote
selwakekup
tun_enqueue
ether_output
ip_output
ip_forward
ip_input_if
ipv4_input
ether_input
if_input_process
The other 3 cpu cores appeared to be in ipi handlers. (Image in that
imgur link)
-dv
