diff --git a/en/releases/5.4R/todo.sgml b/en/releases/5.4R/todo.sgml
index fd75bdfe5f..916ea19f80 100644
--- a/en/releases/5.4R/todo.sgml
+++ b/en/releases/5.4R/todo.sgml
@@ -1,188 +1,188 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
 <!ENTITY base CDATA "../..">
 <!ENTITY email 'freebsd-qa'>
-<!ENTITY date "$FreeBSD: www/en/releases/5.4R/todo.sgml,v 1.2 2004/10/22 10:14:44 rwatson Exp $">
+<!ENTITY date "$FreeBSD: www/en/releases/5.4R/todo.sgml,v 1.3 2004/10/22 10:17:42 rwatson Exp $">
 <!ENTITY title "FreeBSD 5.4 Open Issues">
 <!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
 <!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
 <!-- Status levels -->
 <!ENTITY status.na "<font color=green>N/A</font>">
 <!ENTITY status.done "<font color=green>Done</font>">
 <!ENTITY status.wip "<font color=blue>In&nbsp;progress</font>">
 <!ENTITY status.untested "<font color=orange>Needs&nbsp;testing</font>">
 <!ENTITY status.new "<font color=red>Not&nbsp;done</font>">
 <!ENTITY status.unknown "<font color=red>Unknown</font>">
 
 <!ENTITY url.cvsweb "http://www.freebsd.org/cgi/cvsweb.cgi">
 <!ENTITY url.mid "http://docs.freebsd.org/cgi/mid.cgi?">
 <!ENTITY url.pr "http://www.freebsd.org/cgi/query-pr.cgi?">
 ]>
 
 <!--
 
   Changes to this list MUST NOT be committed without approval of
   Release Engineering Team (re@FreeBSD.org) (for general items) or
   Documentation Engineering Team (doceng@FreeBSD.org) (for doc-related
   items).
 
 -->
 
 <html>
 &header;
 
 <h1>Open Issues</h1>
 
 <p>This is the beginning of a list of open issues that need to be worked on
   or resolved for FreeBSD 5.4.  If you have any updates for this list, please
   e-mail re@FreeBSD.org.  The feature list for 5.4 is still a work in
   progress, so items may be added, removed, or modified before we're done.
   </p>
 
 <h3>Show stopper defects for 5.4-RELEASE</h3>
 
 <table border=1 width="100%">
   <tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
   </tr>
 
   <!-- Woo hoo, none yet! -->
 
 </table>
 
 <h3>Required features for 5.4-RELEASE</h3>
 
 <table border=1 width="100%">
   <tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
   </tr>
 
   <tr>
     <td>Entropy harvesting optimizations</td>
     <td>&status.wip;</td>
     <td>&a.rwatson;, &a.markm;</td>
     <td>Entropy harvesting in the interrupt and incoming packet paths
       currently involves a large number of mutex operations.  In order to
       improve performance, it is desirable to reduce the number of mutex
       operations substantially.  Improvements in the harvesting locking
       scheme have been merged to 6.x, but are considered too risky at this
       stage to be merged to 5.x until after 5.3.</td>
   </tr>
 
   <tr>
     <td>ACL_MASK override of umask support in UFS</td>
     <td>&status.new;</td>
     <td>&a.rwatson;</td>
     <td>Many systems supporting POSIX.1e ACLs permit a minor violation
       to that specification, in which the ACL_MASK entry overrides the
       umask, rather than being intersected with it.  The resulting
       semantics can be useful in group-oriented environments, and as
       such would be very helpful on FreeBSD.</td>
   </tr>
 
   <tr>
     <td>busdma in all PCI drivers</td>
     <td>&status.wip;</td>
     <td>--</td>
     <td>All PCI drivers must use busdma for DMA; no use of vtophys() will
       be permitted for any recent device driver.  ISA drivers may be
       exempt.</td>
   </tr>
 
   <tr>
     <td>MAC Framework Labeling and Access Control for System V IPC</td>
     <td>&status.wip;</td>
     <td>&a.rwatson;</td>
     <td>Currently, the MAC Framework in the FreeBSD source tree does not
        provide for any additional protections of System V IPC (shm, sem,
        msq).  The TrustedBSD MAC development branch contains labeling and
        access control extensions for System V IPC, and this will be merged
        for 5.4-RELEASE.  This includes work to separate the kernel and user
        data structures to improve ABI resilience of the IPC implementations.
        </td>
   </tr>
 
   <tr>
     <td>KAME IPSEC without the Giant Lock</td>
     <td>&status.wip;</td>
     <td>&a.gnn;</td>
     <td>Currently, the KAME IPSEC implementation contains inadequate locking
       to operate without the Giant lock over the network stack, forcing
       kernels compiled with the KAME IPSEC implementation (not FAST_IPSEC)
       to run the network stack with the Giant lock, reducing parallelism,
       increasing lock contention, and increasing latency by preventing
       preemption.  For 5.4-RELEASE, it is desirable to complete the locking
       work for KAME IPSEC so that it can run without the Giant lock.</td>
   </tr>
 
 </table>
 
 <h3>Desired features for 5.4-RELEASE</h3>
 
 <table border=1 width="100%">
   <tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
   </tr>
 
   <tr>
     <td>MAC support for NFS Server</td>
     <td>&status.new;</td>
     <td>&a.rwatson;</td>
     <td>Currently, MAC protections are enforced only on locally originated
       file system operations (VOPs), and not on RPCs generated via the
       NFS server.  Improvements in NFS server credential handling are
       required to correct this problem, as well as the introduction of
       new entry points to properly label NFS credentials and perform
       enforcement properly.</td>
   </tr>
 
   <tr>
     <td>All Network Interface Drivers MPSAFE</td>
     <td>&status.wip;</td>
     <td>--</td>
     <td>Currently, some network interface drivers are not safe without the
       Giant lock due to missing synchronization.  These drivers are protected
       by running non-INTR_MPSAFE and with the IFF_NEEDSGIANT flag set, which
       cause interrupt threads to acquire the Giant lock before executing the
       driver's interrupt handler, and to perform if_start (interface
       transmit start) asynchronously once the Giant lock can be acquired.
       This results in these drivers performing less well due to increased
       lock contention, decreased ability to preempt, and latency associated
       with asynchronous launching of latency-critical events.  For 5.4, all
       network drivers should be able to operate without the Giant lock.</td>
   </tr>
 
   <tr>
     <td>NetIPX without the Giant Lock</td>
     <td>&status.wip;</td>
     <td>&a.rwatson;</td>
     <td>Currently, the IPX/SPX (netipx) implementation contains inadequate
       locking to operate without the Giant lock over the network stack,
       forcing kernels compiled with IPX support to run the network stack
       with the Giant lock, reducing parallelism, increasing lock contention,
       and increasing latency by preventing preemption.  For 5.4-RELEASE, it
       is desirable to complete the locking work for IPX so that it can run
       without the Giant lock.</td>
   </tr>
 
 </table>
 
 <h3>Documentation items that must be resolved for 5.4</h3>
 
 <table border=1 width="100%">
   <tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
   </tr>
 
 </table>
 
 
 <h3>Testing focuses for 5.4-RELEASE</h3>
 
 <table border=1 width="100%">
   <tr><th>Issue</th><th>Status</th><th>Responsible</th><th>Description</th>
   </tr>
 
   <!-- Woo hoo, none yet! -->
 
-</trable>
+</table>
 
     &footer;
 
   </body>
 </html>

Issue	Status	Responsible	Description
Entropy harvesting optimizations	&status.wip;	&a.rwatson;, &a.markm;	Entropy harvesting in the interrupt and incoming packet paths currently involves a large number of mutex operations. In order to improve performance, it is desirable to reduce the number of mutex operations substantially. Improvements in the harvesting locking scheme have been merged to 6.x, but are considered too risky at this stage to be merged to 5.x until after 5.3.
ACL_MASK override of umask support in UFS	&status.new;	&a.rwatson;	Many systems supporting POSIX.1e ACLs permit a minor violation to that specification, in which the ACL_MASK entry overrides the umask, rather than being intersected with it. The resulting semantics can be useful in group-oriented environments, and as such would be very helpful on FreeBSD.
busdma in all PCI drivers	&status.wip;	--	All PCI drivers must use busdma for DMA; no use of vtophys() will be permitted for any recent device driver. ISA drivers may be exempt.
MAC Framework Labeling and Access Control for System V IPC	&status.wip;	&a.rwatson;	Currently, the MAC Framework in the FreeBSD source tree does not provide for any additional protections of System V IPC (shm, sem, msq). The TrustedBSD MAC development branch contains labeling and access control extensions for System V IPC, and this will be merged for 5.4-RELEASE. This includes work to separate the kernel and user data structures to improve ABI resilience of the IPC implementations.
KAME IPSEC without the Giant Lock	&status.wip;	&a.gnn;	Currently, the KAME IPSEC implementation contains inadequate locking to operate without the Giant lock over the network stack, forcing kernels compiled with the KAME IPSEC implementation (not FAST_IPSEC) to run the network stack with the Giant lock, reducing parallelism, increasing lock contention, and increasing latency by preventing preemption. For 5.4-RELEASE, it is desirable to complete the locking work for KAME IPSEC so that it can run without the Giant lock.
Issue	Status	Responsible	Description
MAC support for NFS Server	&status.new;	&a.rwatson;	Currently, MAC protections are enforced only on locally originated file system operations (VOPs), and not on RPCs generated via the NFS server. Improvements in NFS server credential handling are required to correct this problem, as well as the introduction of new entry points to properly label NFS credentials and perform enforcement properly.
All Network Interface Drivers MPSAFE	&status.wip;	--	Currently, some network interface drivers are not safe without the Giant lock due to missing synchronization. These drivers are protected by running non-INTR_MPSAFE and with the IFF_NEEDSGIANT flag set, which cause interrupt threads to acquire the Giant lock before executing the driver's interrupt handler, and to perform if_start (interface transmit start) asynchronously once the Giant lock can be acquired. This results in these drivers performing less well due to increased lock contention, decreased ability to preempt, and latency associated with asynchronous launching of latency-critical events. For 5.4, all network drivers should be able to operate without the Giant lock.
NetIPX without the Giant Lock	&status.wip;	&a.rwatson;	Currently, the IPX/SPX (netipx) implementation contains inadequate locking to operate without the Giant lock over the network stack, forcing kernels compiled with IPX support to run the network stack with the Giant lock, reducing parallelism, increasing lock contention, and increasing latency by preventing preemption. For 5.4-RELEASE, it is desirable to complete the locking work for IPX so that it can run without the Giant lock.