Language, emphasize, typo in code

diff --git a/docs/howtos/HowToDebugVKernels/index.mdwn b/docs/howtos/HowToDebugVKernels/index.mdwn
index c27fabf..8e9e6a9 100644 (file)
--- a/docs/howtos/HowToDebugVKernels/index.mdwn
+++ b/docs/howtos/HowToDebugVKernels/index.mdwn
@@ -135,6 +135,7 @@ At this point we can examine the data of various variables. Keep in mind that ba
 
 
 Let's try this time to break into the kernel _before_ it crashes. sys_ktrace() seems like a good candidate.
+We stop the old vkernel and fire off a new one. Once we are logged in, we attach to it as before:
 
     # gdb kernel 25532
     GNU gdb 6.7.1
@@ -148,7 +149,7 @@ Next we type 'c' in the gdb prompt to resume vkernel execution:
     (gdb) c
     Continuing.
 
-Now we go to our vkernel and type the offending command:
+We switch now to our vkernel and type in the offending command:
 
     # ktrace -c 
 
@@ -158,7 +159,9 @@ Gdb stops the execution of vkernel and a message pops up in gdb buffer:
     83          __asm ("movl %%fs:globaldata,%0" : "=r" (gd) : "m"(__mycpu__dummy));
     (gdb) 
 
-We navigate through source code with the 'step' and 'next' gdb commands. They are identical, except that 'step' follows function calls. When we meet this call:
+At this point, kernel hasn't paniced yet, because we are inside sys_ktrace().
+We navigate through source code with the 'step' and 'next' gdb commands.
+They are identical, except that 'step' follows function calls. When we meet this call:
 
     276                     allproc_scan(ktrace_clear_callback, &info);
 
@@ -171,13 +174,13 @@ Here p is a pointer to the current process:
     (gdb) print p
     $1 = (struct proc *) 0x57098c00
 
-Let's see if this process is traced (if it is, the p->p_tracenode shall point to a vnode where all logs are directed):
+Let's see if this process is traced (if it is, the p->p_tracenode->kn_vp shall point to a vnode where all logs are directed):
 
     (gdb) print p->p_tracenode
     $2 = (struct ktrace_node *) 0x0
     (gdb) 
 
-Oops. There is no trace to a vnode for this process. The code will try to access p->p_tracenode and is bound to crash. This is the zero virtual address we saw before.
+Oops. There is no trace to any vnode, whatsoever, for this process. The code will try to access p->p_tracenode and is bound to crash. This is the _zero virtual address_ we saw before.
 
 # Possible places of confusion