From seth@psychotic.aberrant.org  Wed Apr 18 07:53:11 2001
Return-Path: <seth@psychotic.aberrant.org>
Received: from psychotic.aberrant.org (psychotic.aberrant.org [64.81.134.141])
	by hub.freebsd.org (Postfix) with ESMTP id 0F9BB37B424
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 18 Apr 2001 07:53:11 -0700 (PDT)
	(envelope-from seth@psychotic.aberrant.org)
Received: (from seth@localhost)
	by psychotic.aberrant.org (8.9.3/8.9.3) id KAA13572;
	Wed, 18 Apr 2001 10:53:10 -0400 (EDT)
	(envelope-from seth)
Message-Id: <200104181453.KAA13572@psychotic.aberrant.org>
Date: Wed, 18 Apr 2001 10:53:10 -0400 (EDT)
From: Seth <seth@psychotic.aberrant.org>
Reply-To: seth@psychotic.aberrant.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: Fix various typos in dc(4) manpage; remove redundancies
X-Send-Pr-Version: 3.2

>Number:         26672
>Category:       docs
>Synopsis:       Fix various typos in dc(4) manpage; remove redundancies
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dd
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 18 08:00:02 PDT 2001
>Closed-Date:    Wed Apr 25 19:05:15 PDT 2001
>Last-Modified:  Wed Apr 25 19:05:24 PDT 2001
>Originator:     Seth
>Release:        FreeBSD 4.0-20000710-STABLE i386 (not quite relevant)
>Organization:
>Environment:

$FreeBSD: /c/ncvs/src/share/man/man4/dc.4,v 1.6.2.4 2001/03/06 19:08:10 ru Exp $

>Description:

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.

>How-To-Repeat:

man 4 dc

>Fix:

Patch as follows (diff -u output):


--- 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



<end of patch<
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->dd 
Responsible-Changed-By: dd 
Responsible-Changed-When: Wed Apr 18 12:47:51 PDT 2001 
Responsible-Changed-Why:  
I'll fix this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26672 
State-Changed-From-To: open->analyzed 
State-Changed-By: dd 
State-Changed-When: Thu Apr 19 20:47:55 PDT 2001 
State-Changed-Why:  
Committed to -current, thanks!  I'll MFC this after the code freeze. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26672 
State-Changed-From-To: analyzed->closed 
State-Changed-By: dd 
State-Changed-When: Wed Apr 25 19:05:15 PDT 2001 
State-Changed-Why:  
MFC'd. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=26672 
>Unformatted:
