Bug 26672

Various typos in dc(4) manpage.  Also, section describing NWAY problems in 
the PNIC 82c168 chipset repeats itself in BUGS.  I made a reference to BUGS
in the DESCRIPTION section and removed the details.

Fix: Patch as follows (diff -u output):




<end of patch<--y5mJkKrxDUUuTgEREpDCPDTLaJIXuv6sWKixVeFFO1DVvMrz
Content-Type: text/plain; name="file.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="file.diff"

--- dc.4	Wed Apr 18 10:35:58 2001
+++ dc.n	Wed Apr 18 10:47:41 2001
@@ -77,7 +77,7 @@
 filtering.
 .Pp
 Some clone chips duplicate the 21143 fairly closely while others
-only maintain superficial simularities.
+only maintain superficial similarities.
 Some support only MII
 media attachments.
 Others use different receiver filter programming
@@ -92,7 +92,7 @@
 of these chipsets in order to keep special case code to a minimun.
 .Pp
 These chips are used by many vendors which makes it
-difficult provide a complete list of all supported cards.
+difficult to provide a complete list of all supported cards.
 The
 following NICs are known to work with the
 .Nm
@@ -153,8 +153,9 @@
 Note: the built-in NWAY autonegotiation on the original PNIC 82c168
 chip is horribly broken and is not supported by the
 .Nm
-driver at this time: the chip will operate in any speed or duplex
-mode, however these must be set manually.
+driver at this time (see the 
+.Nm BUGS
+section for more details).
 The original 82c168 appears
 on very early revisions of the LinkSys LNE100TX and Matrox FastNIC.
 .It 10baseT/UTP
@@ -206,11 +207,12 @@
 A fatal initialization error has occurred.
 .It "dc%d: watchdog timeout"
 A packet was queued for transmission and a transmit command was
-issued, however the device failed to acknowledge the transmission
+issued, but the device failed to acknowledge the transmission
 before a timeout expired.
 This can happen if the device is unable
 to deliver interrupts for some reason, of if there is a problem with
-the network connection (cable).
+the network connection (cable or network equipment) that results in a loss
+of link.
 .It "dc%d: no memory for rx list"
 The driver failed to allocate an mbuf for the receiver ring.
 .It "dc%d: TX underrun -- increasing TX threshold"
@@ -334,7 +336,7 @@
 instead of just the expected one.
 The
 .Nm
-driver detects this condition and will salvage the frame, however
+driver detects this condition and will salvage the frame; however,
 it incurs a serious performance penalty in the process.
 .Pp
 The PNIC chips also sometimes generate a transmit underrun error when
@@ -348,7 +350,7 @@
 The ADMtek AL981 chip (and possibly the AN985 as well) has been observed
 to sometimes wedge on transmit: this appears to happen when the driver
 queues a sequence of frames which cause it to wrap from the end of the
-the transmit descriptor ring back to the beginning.
+transmit descriptor ring back to the beginning.
 The
 .Nm
 driver attempts to avoid this condition by not queing any frames past
How-To-Repeat: 
man 4 dc