[realtek] Ping doesn't respond anymore after 5 good tests

[Donald Becker]

On Fri, 5 Jan 2001, Alain SMEDTS wrote:

> Hereby the output of ping (stopped with Ctrl C):
> # ping 172.17.4.100
> PING 172.17.4.100 (172.17.4.100): 56 data bytes
> 64 bytes from 172.17.4.100: icmp_seq=0 ttl=128 time=0.8 ms
> 64 bytes from 172.17.4.100: icmp_seq=1 ttl=128 time=0.2 ms
> 64 bytes from 172.17.4.100: icmp_seq=2 ttl=128 time=0.3 ms
> 64 bytes from 172.17.4.100: icmp_seq=3 ttl=128 time=0.3 ms
> --- 172.17.4.100 ping statistics ---39 packets transmitted, 4 packets
> received, 89% packet loss

Presumably the interface is hosed at this point..

> The Compaq is a Pentium 100 Mhz system with 32Mb memory.

That's an old, relatively slow system with a v1.0 PCI bus.  But the rtl8139
should still work.

> In /var/log/messages I find the following messages occasionaly:
> Jan  5 07:58:48 Volcanus kernel: eth1: Oversized Ethernet frame, status
> 31302f2e!

This is reporting
3130xxxx	Packet size 0x3130, or >12KB!
2000   Broadcast packet (curious, since ARP presumably happened before now)
0f00    Unused bits
0020   Invalid symbol
0008   Over-long packet
0004   CRC error
0002   alignment error

So this is reporting a monsterously large packet on the wire.  I would
normally assume that the Rx data ring pointer had been corrupted, but the
error bits make sense for some transceiver-level Bad Thing.

What does rtl8139 report after the Rx stops?

> This is the output of the driver:
> Jan  5 08:16:54 Volcanus kernel:  http://www.scyld.com/network/rtl8139.html
> Jan  5 08:16:54 Volcanus kernel: eth1: SMC1211TX EZCard 10/100 (RealTek
> RTL8139) at 0x7100, IRQ 5, 00:10:b5:03:63:1d.

This is version 1.12, correct?

> > I used rtl8139.o delivered with Slackware, it is version 1.07. I upgraded
> > to RTL8139 v1.12, but the problem is the same. I tried three different NIC
...
> > ENW-9500). Those NIC work fine in another Linux box with the same
> > drivers.


> I tried with debug=7 and then I can ping without any problems (stopped it
> after more than 400 good packages). However this isn't a permanent solution
> as the response times are rather high. I didn't find any debug messages in
> /var/log/messages, or is this debug info put in another file?

I put the following line in /etc/syslog.conf
kern.debug;*.debug;*.*		-/var/log/debug


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