diff --git a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml
index aec79065c0..84c219ac37 100644
--- a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml
+++ b/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml
@@ -19,7 +19,7 @@
 
     <copyright>
       <year>2002</year>
-      <year>2003</year>
+      <year>2004</year>
       <holder>John Baldwin</holder>
       <holder>Robert Watson</holder>
     </copyright>
@@ -257,6 +257,11 @@
     <sect2>
       <title>Kernel Preemption and Critical Sections</title>
 
+      <note>Please note that full kernel preemption as described below
+	is not currently implemented in the CVS tree.  An implementation
+	similar to that described below has been implemented before in a
+	prototype tree.</note>
+
       <sect3>
 	<title>Kernel Preemption in a Nutshell</title>
 
@@ -305,8 +310,8 @@
 
 	<para>In order to minimize latency, preemptions inside of a
 	  critical section are deferred rather than dropped.  If a
-	  thread is made runnable that would normally be preempted to
-	  outside of a critical section, then a per-thread flag is set
+	  thread that would normally be preempted to is made runnable while the current thread is in a critical section,
+	  then a per-thread flag is set
 	  to indicate that there is a pending preemption.  When the
 	  outermost critical section is exited, the flag is checked.
 	  If the flag is set, then the current thread is preempted to
@@ -329,8 +334,7 @@
 	  to split out the MD API from the MI API and only use it in
 	  conjunction with the MI API in the spin mutex
 	  implementation.  If this approach is taken, then the MD API
-	  likely would need a rename to show that it is a separate API
-	  now.</para>
+	  likely would need a rename to show that it is a separate API.</para>
       </sect3>
 
       <sect3>
@@ -366,8 +370,8 @@
 	  run another non-realtime kernel thread, the kernel may
 	  switch out the executing thread just before it is about to
 	  sleep or execute.  The cache on the CPU must then adjust to
-	  the new thread.  When the kernel returns to the interrupted
-	  CPU, it must refill all the cache information that was lost.
+	  the new thread.  When the kernel returns to the preempted
+	  thread, it must refill all the cache information that was lost.
 	  In addition, two extra context switches are performed that
 	  could be avoided if the kernel deferred the preemption until
 	  the first thread blocked or returned to userland.  Thus, by
@@ -410,6 +414,8 @@
 	thread is preempted it should not migrate to another
 	CPU.</para>
 
+      <note>Need to describe the thread pinning API that Jeff implemented here instead.</note>
+
       <para>One possible implementation is to use a per-thread nesting
 	count <varname>td_pinnest</varname> along with a
 	<varname>td_pincpu</varname> which is updated to the current
@@ -471,7 +477,7 @@
 	code is careful to leave the list in a consistent state
 	while releasing the mutex.  If <constant>DIAGNOSTIC</constant>
 	is enabled, then the time taken to execute each function is
-	measured, and a warning generated if it exceeds a
+	measured, and a warning is generated if it exceeds a
 	threshold.</para>
     </sect2>
   </sect1>
@@ -760,6 +766,29 @@
   <sect1 id="smp-implementation-notes">
     <title>Implementation Notes</title>
 
+    <sect2>
+      <title>Sleep Queues</title>
+
+      <para>- Lookup/release</para>
+
+      <para>- Adding & waiting.</para>
+
+      <para>- Timeout and signal catching.</para>
+
+      <para>- Aborting a sleep.</para>
+    </sect2>
+
+    <sect2>
+      <title>Turnstiles</title>
+
+      <para>- Compare/contrast with sleep queues.</para>
+
+      <para>- Lookup/wait/release.
+        - Describe TDF_TSNOBLOCK race.</para>
+
+      <para>- Priority propagation.</para>
+    </sect2>
+
     <sect2>
       <title>Details of the Mutex Implementation</title>
 
@@ -779,9 +808,7 @@
 	<para>- Describe the races with contested mutexes</para>
 
 	<para>- Why it is safe to read mtx_lock of a contested mutex
-	  when holding sched_lock.</para>
-
-	<para>- Priority propagation</para>
+	  when holding the turnstile chain lock.</para>
       </sect3>
     </sect2>
 
@@ -808,12 +835,12 @@
     <sect2>
       <title>Other Random Questions/Topics</title>
 
-      <para>Should we pass an interlock into
+      <para>- Should we pass an interlock into
 	<function>sema_wait</function>?</para>
 
-      <para>- Generic turnstiles for sleep mutexes and sx locks.</para>
-
       <para>- Should we have non-sleepable sx locks?</para>
+
+      <para>- Add some info about proper use of reference counts.</para>
     </sect2>
   </sect1>