eth0: Transmit error, Tx status register 82.

[Michael Packer]

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01BF1094.550A3600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I have attached to this a patch that I found somewhere on the web....
this fixed the problem for me...


--
Michael Packer -- Stingray Powerboats -- http://www.stingrayboats.com

Visit here to make money while surfing the web!
http://alladvantage.com/go.asp?refid=ATA568


----- Original Message -----
From: Andrew Lauder <admin@neuimage.com>
To: <linux-vortex-bug@cesdis1.gsfc.nasa.gov>
Sent: Wednesday, October 06, 1999 6:34 PM
Subject: eth0: Transmit error, Tx status register 82.


> I have a DEC Alpha 21064A Cabriolet box, running redhat 6.0 axp, and
I
> continue to get this error in my syslog.
>
> eth0: Transmit error, Tx status register 82.
>
> If something is wrong, what can I do to fix it, should I just not
worry
> about it?
>
> Thanks
> -Andy Lauder
> admin@neuimage.com
>

------=_NextPart_000_0037_01BF1094.550A3600
Content-Type: text/plain;
	name="TX-problem.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="TX-problem.txt"

=0A=
                            Re: Transmit Errors??!=0A=
                                       =0A=
   Bill Paul (wpaul@ctr.columbia.edu)=0A=
   Thu, 22 Oct 1998 16:44:13 -0400 (EDT)=0A=
   =0A=
   The transmit error codes for the 3c905B are as follows:=0A=
   =0A=
   /*=0A=
   * TX status codes=0A=
   */=0A=
   #define XL_TXSTATUS_RECLAIM 0x02 /* 3c905B only */=0A=
   #define XL_TXSTATUS_OVERFLOW 0x04=0A=
   #define XL_TXSTATUS_MAXCOLS 0x08=0A=
   #define XL_TXSTATUS_UNDERRUN 0x10=0A=
   #define XL_TXSTATUS_JABBER 0x20=0A=
   #define XL_TXSTATUS_INTREQ 0x40=0A=
   #define XL_TXSTATUS_COMPLETE 0x80=0A=
   =0A=
   The value is in hex, so 0x82 really means both 0x80 (transmit =
complete)=0A=
   and 0x02 (reclaim error). A reclaim error means that a transmission =
error=0A=
   (most likely too many collisions) was detected after part of the =
transmit=0A=
   FIFO was already reclaimed. In other words, the chip had already=0A=
   transmitted the packet and was in the process of flushing it from its=0A=
   memory when it noticed the error.=0A=
   =0A=
   Note that there is a special command to set the transmit reclaim=0A=
   threshold:=0A=
   =0A=
   #define XL_CMD_SET_TX_RECLAIM 0xC000 /* 3c905B only */=0A=
   =0A=
   There is also a register in register window 5 for reading the current=0A=
   transmit reclaim threshold setting:=0A=
   =0A=
   /*=0A=
   * Window 5=0A=
   */=0A=
   #define XL_W5_STAT_ENB 0x0C=0A=
   #define XL_W5_INTR_ENB 0x0A=0A=
   #define XL_W5_RECLAIM_THRESH 0x09 /* 3c905B only */=0A=
   #define XL_W5_RX_FILTER 0x08=0A=
   #define XL_W5_RX_EARLYTHRESH 0x06=0A=
   #define XL_W5_TX_AVAILTHRESH 0x02=0A=
   #define XL_W5_TX_STARTTHRESH 0x00=0A=
   =0A=
   As the comments suggest, only the 3c90xB 'cyclone' chips have this=0A=
   feature: it's not available on the older 3c90x 'boomerang' series.=0A=
   This means the error can only happen on 3c900B or 3c905B (or 3c980)=0A=
   adapters.=0A=
=0A=
   =0A=
   You can try to reduce these errors by increasing the transmit reclaim=0A=
   threshold. This should probably be done in the vortex_open() function.=0A=
   I don't have a Linux system available so I can't really generate a=0A=
=0A=
   working source patch for the driver, but here's something which should=0A=
   work:=0A=
   =0A=
=0A=
   - In the 3c59x.c source file, find the vortex_open() routine. Near the=0A=
   end, you should see the following code:=0A=
   =0A=
   [...]=0A=
   if (vp->full_bus_master_tx) { /* Boomerang bus master Tx. */=0A=
   dev->hard_start_xmit =3D &boomerang_start_xmit;=0A=
   vp->cur_tx =3D vp->dirty_tx =3D 0;=0A=
   outb(PKT_BUF_SZ>>8, ioaddr + TxFreeThreshold); /* Room for a packet.=0A=
   */=0A=
   [...]=0A=
   =0A=
   - Immediately after the outb(), add the following lines:=0A=
   =0A=
   /* Jack up the tx reclaim threshold. */=0A=
   #define XL_CMD_SET_TX_RECLAIM 0xC000=0A=
   outw(XL_CMD_SET_TX_RECLAIM|(PKT_BUF_SZ>>4), ioaddr + EL3_CMD);=0A=
   =0A=
   Ideally, this should only be done if the adapter is a 3c90xB, so there=0A=
   should be some test to check the card type and only set the reclaim=0A=
   threshold if the chip is a cyclone. For now though, this is just a =
kludge=0A=
   to deal with your particular situation. Try modifying your copy of the=0A=
   driver code, recompile the driver and see if this makes any=0A=
   difference.=0A=
   =0A=
   -Bill=0A=
   =0A=
--=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu=0A=
Work:         wpaul@ctr.columbia.edu | Center for Telecommunications =
Research=0A=
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
"Mulder, toads just fell from the sky!" "I guess their parachutes didn't=0A=
open."=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
=0A=
=0A=

------=_NextPart_000_0037_01BF1094.550A3600--