Dave Voutila <[email protected]> writes:
> 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);
> }
Even easier reproduction: if you have 2 machines and can use tcpbench(1)
between them, then while tcpbench is running target it with the above
btrace script. I've found running the script, killing it with ctrl-c,
and re-running it 2-3 times triggers the panic on my laptop.
>
> 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
