[realtek] Oversize ethernet frame causes chip to hang?

Jeff Garzik jgarzik@mandrakesoft.com
Tue, 15 May 2001 14:42:57 -0400


Donald Becker wrote:
> 
> 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.

RealTek encourages use of a low early rx fifo threshold, and
specifically warns against a high, or no, rx fifo threshold, to minimize
occurence of Rx FIFO overflow.  When early rx is possible, 0xfff0 is
used by the chip to indicate the packet is not completely transferred
into the DMA ring buffer.  Both of these are documented in RealTek's
p-guide.pdf, and have also been mentioned by RealTek engineers.

Now, in theory, an 8139 driver should be able to check the BufEmpty bit
of ChipCmd, and stop when it is set.  (which is the current rtl8139.c
behavior afaik)  In practice, with early rx fifo threshold, BufEmpty bit
is -not- set for some early packets, causing the 0xfff0 case to be hit. 
Put a counter on it and get users to report anytime their counter is
non-zero...

Regards,

	Jeff


-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |