When the vkernel is sitting at a db> prompt all vkernel threads representing virtual cpu's except the one handling the db> prompt itself
will be suspended in stopsig(). The backtrace only sees one of the N threads.
+# Additional notes
+## Accessing Vkernels memory
+For those using HEAD, some changes in libkvm have been introduced so vkernel's memory can be accessed directly now on /proc/$pid/mem.
+
+Among other things, you can have a look at vkernel's process list using ps:
+
+
+ # ps axl -M /proc/829/mem -N /var/vkernel/boot/kernel
+ UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
+ 0 0 -1 1 152 0 0 3068 nowork DL ?? 0:00.00 (swapper)
+ 0 1 0 0 152 0 760 3068 wait IL ?? 0:00.00 (init)
+ 77 212 1 0 152 0 788 3068 poll S ?? 0:00.00 (dhclient)
+ 0 323 1 0 152 0 1288 3068 select S ?? 0:00.00 (syslogd)
+ 0 627 1 115 222 0 3332 3068 select I ?? 0:00.00 (sshd)
+ 0 641 1 0 152 0 3772 3068 select S ?? 0:00.00 (sendmail)
+ 25 645 1 22 165 0 3668 3068 pause I ?? 0:00.00 (sendmail)
+ 0 0 0 0 0 -52 0 0 - ? con- 0:00.00 ()
+ 0 0 0 0 0 -52 0 0 - ? con- 0:00.00 ()
+ 0 0 0 0 0 -52 0 0 - ? con- 0:00.00 ()
+ 0 188 1 2 153 0 788 3068 poll I v0- 0:00.00 (dhclient)
+
+
## Gdb + vkernel issues
gdb and vkernel (SMP or not) don't play well together anymore. It is possible to get into
a state where the vkernel is in state "stop" and the vkernel is in "wait", and nothing moves on.