[realtek] Oversize ethernet frame causes chip to hang?
Lynn Winebarger
lynn@freespeech.org
Tue, 15 May 2001 11:00:17 -0600 (MDT)
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,"