[realtek] Oversize ethernet frame causes chip to hang?

[Loh Kok Meng]

Hi,

I'm using version 1.13 of rtl8139.c and I've been getting oversized
ethernet frames very often in my system and it causes the network driver
to lock up. I believe my problems are what you (and many others in the
list) have experienced.

I've tried the reset code mentioned to no avail. However, I went back to
an older version of rtl8139.c - version 1.08 and the problems went away.
You might want to give it a try and see if it works for you.

Regards,
KokMeng Loh
Celestix Networks

Lynn Winebarger wrote:
> 
> On Tue, 15 May 2001, Donald Becker wrote:
> > On Mon, 14 May 2001, Lynn Winebarger wrote:
> >
> > >    I've been having problems with oversize ethernet frames, and noticed
> > > this code in the driver:
> >
> > What driver version are you using?
> >
>    1.13 with a patch suggested on the list (included at the end).
> 
> > 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);
> >
> > The reason for the comment is that the documentation implies that the
> > chip should continue operation without a reset.
> 
>    I can report that the device stops responding (without going down), but
> an ifdown/ifup resumes operation.  With 2 cards in the machine, 1 of cards
> getting an oversize frame seems to cause the other card to experience a
> memory squeeze (and then it appears to go down for all intents and
> purposes).  We have about 10 machines with 2 of these cards in each,
> though only 2 or three get heavily used.
>    Does this code go right after A.C's comment?
>    Is there any way to track down what's putting in an oversize frame?
> 
> Lynn
> 
> diff -Naur linux-2.2.19/drivers/net/rtl8139.c
> linux-2.2.19-mod/drivers/net/rtl8139.c
> --- linux-2.2.19/drivers/net/rtl8139.c  Tue Jan  9 01:20:15 2001
> +++ linux-2.2.19-mod/drivers/net/rtl8139.c      Sat Apr 14 01:56:09 2001
> @@ -24,7 +24,7 @@
> 
>  /* These identify the driver base version and may not be removed. */
>  static const char versionA[] =
> -"rtl8139.c:v1.13 1/9/2001 Donald Becker, becker@scyld.com.\n";
> +"rtl8139.c:v1.13a 1/9/2001 Donald Becker, becker@scyld.com.\n";
>  static const char versionB[] =
>  " http://www.scyld.com/network/rtl8139.html\n";
> 
> @@ -1186,6 +1186,23 @@
>                                 printk(" %2.2x", rx_ring[ring_offset +
> i]);
>                         printk(".\n");
>                 }
> +
> +               /* 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.
> +                */
> +               if (rx_size == 0xfff0)
> +                       {
> +                               if (debug > 1)
> +                                       printk(KERN_DEBUG"%s: Tried
> copying when chip was copying"
> +                                                  , dev->name);
> +                               break;
> +                       }
>                 if (rx_status &
> (RxBadSymbol|RxRunt|RxTooLong|RxCRCErr|RxBadAlign)) {
>                         if (debug > 1)
>                                 printk(KERN_DEBUG"%s: Ethernet frame had
> errors,"
> 
> _______________________________________________
> realtek mailing list
> realtek@scyld.com
> http://www.scyld.com/mailman/listinfo/realtek