From owner-freebsd-doc Wed Apr 18 8: 0:12 2001 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2C12B37B42C for ; Wed, 18 Apr 2001 08:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f3IF03Z93881; Wed, 18 Apr 2001 08:00:03 -0700 (PDT) (envelope-from gnats) Received: from psychotic.aberrant.org (psychotic.aberrant.org [64.81.134.141]) by hub.freebsd.org (Postfix) with ESMTP id 0F9BB37B424 for ; 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 Reply-To: seth@psychotic.aberrant.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/26672: Fix various typos in dc(4) manpage; remove redundancies Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 26672 >Category: docs >Synopsis: Fix various typos in dc(4) manpage; remove redundancies >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 18 08:00:02 PDT 2001 >Closed-Date: >Last-Modified: >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 Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message