[realtek] Oversize ethernet frame causes chip to hang?

[Donald Becker]

On Tue, 15 May 2001, Lynn Winebarger wrote:
> On Tue, 15 May 2001, Donald Becker wrote:
> > On Mon, 14 May 2001, Lynn Winebarger wrote:
> > 
> > >    I'fve been having problems with oversize ethernet frames, and noticed
> > > this code in the driver:
>    1.13 with a patch suggested on the list (included at the end).
...
> +		/* E. Gill */
> +		/* Note from BSD driver:
> +		 * Here's a totally undocumented fact for you. When the
> +		 * RealTek chip is in the process of copying a packet into
> +		 * RAM for you, the length will be 0xfff0. If you spot a
> +		 * packet header with this value, you need to stop. The
> +		 * datasheet makes absolutely no mention of this and
> +		 * RealTek should be shot for this.
> +		 */

I believe that this is a bogus patch.

The BSD driver tries to avoid reading a register on the chip, which
costs a PCI transaction.  Instead it polls the receive ring in main
memory.  Of course the datasheet makes no mention of this -- it is not
the documented way to use the chip!

The Linux rtl8139 driver should never progress to an not-yet-complete
receive header, and thus should never see the 0xfff0 value.

> > Yes.  The code immediately below resets the receiver:
> > 
> > 	/* Reset the receiver, based on RealTek recommendation. (Bug?) */
> > 	tp->cur_rx = 0;
> > 	outb(CmdTxEnb, ioaddr + ChipCmd);
> > 	/* A.C.: Reset the multicast list. */
> > 	set_rx_mode(dev);
> > 	outb(CmdRxEnb | CmdTxEnb, ioaddr + ChipCmd);
>
>    Does this code go right after A.C's comment?

This code _is_ immediately after Alan Cox's ("A.C.") comment.

>    Is there any way to track down what's putting in an oversize frame?

It's usually a duplex mismatch combining two packets, although it might
be a machine trying to do VLAN things.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993