diff options
Diffstat (limited to 'static/netbsd/man4/dge.4 3.html')
| -rw-r--r-- | static/netbsd/man4/dge.4 3.html | 126 |
1 files changed, 0 insertions, 126 deletions
diff --git a/static/netbsd/man4/dge.4 3.html b/static/netbsd/man4/dge.4 3.html deleted file mode 100644 index 5ba6f342..00000000 --- a/static/netbsd/man4/dge.4 3.html +++ /dev/null @@ -1,126 +0,0 @@ -<table class="head"> - <tr> - <td class="head-ltitle">DGE(4)</td> - <td class="head-vol">Device Drivers Manual</td> - <td class="head-rtitle">DGE(4)</td> - </tr> -</table> -<div class="manual-text"> -<section class="Sh"> -<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1> -<p class="Pp"><code class="Nm">dge</code> — <span class="Nd">Intel - i82597EX Ten Gigabit Ethernet driver</span></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1> -<p class="Pp"><code class="Cd">dge* at pci? dev ? function ?</code></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1> -<p class="Pp">The <code class="Nm">dge</code> device driver supports the Intel - i82597EX PRO/10GbE LR Ethernet adapter, which uses a single mode fiber - (1310nm) interface.</p> -<p class="Pp">The i82597EX supports IPv4/TCP/UDP checksumming in hardware, as - well as TCP Segmentation Offloading (TSO). The driver does currently only - support the hardware checksumming features. See - <a class="Xr">ifconfig(8)</a> for information on how to enable the hardware - checksum calculations.</p> -<p class="Pp">The driver also makes use of the <a class="Xr">ifconfig(8)</a> - link flags <var class="Ar">link0</var> and <var class="Ar">link1</var> to - set the PCIX burst size. The burst size is set according to this table:</p> -<table class="Bl-column"> - <tr id="link0"> - <td><a class="permalink" href="#link0"><i class="Em">link0</i></a></td> - <td>link1</td> - <td>burst size</td> - </tr> - <tr id="off"> - <td><a class="permalink" href="#off"><code class="Li">off</code></a></td> - <td>off</td> - <td>512</td> - </tr> - <tr id="on"> - <td><a class="permalink" href="#on"><code class="Li">on</code></a></td> - <td>off</td> - <td>1024</td> - </tr> - <tr id="off~2"> - <td><a class="permalink" href="#off~2"><code class="Li">off</code></a></td> - <td>on</td> - <td>2048</td> - </tr> - <tr id="on~2"> - <td><a class="permalink" href="#on~2"><code class="Li">on</code></a></td> - <td>on</td> - <td>4096</td> - </tr> -</table> -<p class="Pp">A larger burst size will increase the transmit capacity of the - card dramatically but may have negative effect on other devices in the - system.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="DIAGNOSTICS"><a class="permalink" href="#DIAGNOSTICS">DIAGNOSTICS</a></h1> -<dl class="Bl-diag"> - <dt>dge%d: Tx packet consumes too many DMA segments, dropping...</dt> - <dd>The packet consisted of too many small mbufs and could therefore not be - loaded into a DMA map. This is most unlikely, the driver can currently - handle up to 100 segments, but over 80 segments has been seen using large - (16k) jumbo frames.</dd> - <dt>dge%s: device timeout (txfree %d txsfree %d txnext %d)</dt> - <dd>The i82597EX had been given packets to send, but didn't interrupt within 5 - seconds. This diagnostic is most likely the result of a hardware failure, - and the chip will be reset to resume normal operation.</dd> - <dt>dge%d: Receive overrun</dt> - <dd>If the computer is under heavy load, the software may not be able to keep - up removing received datagrams from the receive queue, and will therefore - lose datagrams. To avoid this, check that the other end is using the - XON/XOFF protocol, if possible, or increase the receive descriptor ring - size in the driver.</dd> - <dt>dge%d: symbol error</dt> - <dd></dd> - <dt>dge%d: parity error</dt> - <dd>An error in the XGMII communication was detected. This is a hardware error - in the MAC<->PHY communication bus.</dd> - <dt>dge%d: CRC error</dt> - <dd>A CRC error in the received datagram was detected. The error is probably - caused in the fiber communication.</dd> - <dt>dge%d: WARNING: reset failed to complete</dt> - <dd>This is a fatal error and means that the hardware is broken and will most - likely not function correctly.</dd> - <dt>dge%d: unable to allocate or map rx buffer %d error = %d</dt> - <dd>The driver was not able to map a mbuf cluster page to a receive descriptor - entry in the receive ring. Most likely the system has run out of mbuf - clusters or have a too small cluster map. See the errno for more - information.</dd> -</dl> -</section> -<section class="Sh"> -<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE - ALSO</a></h1> -<p class="Pp"><a class="Xr">arp(4)</a>, <a class="Xr">ifmedia(4)</a>, - <a class="Xr">netintro(4)</a>, <a class="Xr">pci(4)</a>, - <a class="Xr">ifconfig(8)</a></p> -</section> -<section class="Sh"> -<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1> -<p class="Pp">The <code class="Nm">dge</code> driver first appeared in - <span class="Ux">NetBSD 2.0</span>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1> -<p class="Pp">The <code class="Nm">dge</code> driver was written by - <span class="An">Anders Magnusson</span> - <<a class="Mt" href="mailto:ragge@ludd.luth.se">ragge@ludd.luth.se</a>>.</p> -</section> -<section class="Sh"> -<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1> -<p class="Pp">There should be an XGMII framework for the driver to use.</p> -</section> -</div> -<table class="foot"> - <tr> - <td class="foot-date">March 18, 2004</td> - <td class="foot-os">NetBSD 10.1</td> - </tr> -</table> |