[realtek] Oversize ethernet frame causes chip to hang?
Tue, 15 May 2001 13:11:13 -0400 (EDT)
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 email@example.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993