Better section name

[ikiwiki.git] / docs / howtos / HowToDebugVKernels / index.mdwn

diff --git a/docs/howtos/HowToDebugVKernels/index.mdwn b/docs/howtos/HowToDebugVKernels/index.mdwn
index 494d45a..971d5b5 100644 (file)
--- a/docs/howtos/HowToDebugVKernels/index.mdwn
+++ b/docs/howtos/HowToDebugVKernels/index.mdwn
@@ -197,9 +197,34 @@ Oops. There is no trace to any vnode for this process. The code will try to acce
 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.
 The only help is to kill gdb, which either makes the vkernel run again, or kills it as well.
 
 See also [this bug report](http://bugs.dragonflybsd.org/issue1301).
+
+Experience has shown that running vkernel with -n1, that is telling it to emulate only 1 CPU, alleviates the issue.
+