Digital DS21140 & ASIX AX88140 with random problems (long)
Mattias Sandgren
mattias@leif.silicon.nu
Fri Jul 16 02:56:56 1999
Hello tulip owners!
I own three tulip cards and I dislike all of them. Dislike is not a word strong
enough to express what I feel about the Tulips however.. :-)
I have experienced random problems with these cards ever since I bought them,
in retrospect I wish I had bought some 3Com cards - they seem reliable but
worth the extra cost.
My situation is that I have a firewall connected to the Internet. Behind the
firewall I have my workstation which is connected to the firewall using a
crosswired UTP-cable.
The firewall is a Pentium 166 (Debian potato, kernel 2.2.8, tulip 0.91e).
The card handling outgoing traffic is an Addtron 10/100 MBit card based on a
Digital DS21140 Tulip rev 34. The card handling traffic to the local network
(my workstation) is a CNet PRO110B based on an ASIX AX88140 rev 3.
The workstation is a dual Celeron 450A (Debian potato, kernel 2.2.10 SMP, tulip
0.91e). This machine also uses an ASIX AX88140 rev 3.
The Digital DS21140 card seems to work more reliable than the other two ASIX
based cards. It also works with every revision of the tulip driver included
with kernels since the 2.0.x series.
The ASIX cards will lock both machines (after a few minutes) with any other
driver version than 0.91e. Before that I used a modified version from CNets
site (which btw doesn't support SMP).
All of the problems I've had with these cards have occured with the Digital
card used both in the workstation and in the firewall but I'm not a network
expert so I haven't been able to tell 100% if the problems can be seen with
the Digital card the same way as with the ASIX cards. Here are my observations:
--
One of the first problems I encountered with the ASIX cards was the unability
to detect replies to arp requests. A machine on the network sees the request
and replies but the ASIX card doesn't seem to care. Easily observed with
iptraf. With an empty arp cache there is no way that you can reach any machine
with a known ip on the segment you're attached to unless that machine connects
to you first. Easily solved on a small static network by adding arp entries
manually but really irritating at a big LAN-party. The card doesn't see arp
replies in Windows neither which might indicate some hardware deviation.
The Digital card seems to do okay on this one.
--
It's great that ftp'ing large files can raise throughput upto 8-9MB/s but
suddenly this might drop to a halt or stutter. Ping times are for some reason
whole seconds:
>From the firewall (192.168.2.1):
PING orion (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=255 time=3000.1 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=255 time=3000.1 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=255 time=3052.5 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=255 time=3000.2 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=255 time=3000.2 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=255 time=3000.2 ms
64 bytes from 192.168.2.2: icmp_seq=6 ttl=255 time=3003.4 ms
64 bytes from 192.168.2.2: icmp_seq=7 ttl=255 time=3000.2 ms
64 bytes from 192.168.2.2: icmp_seq=8 ttl=255 time=3000.2 ms
I've seen 1, 2 and 4 seconds also. The packets don't disappear, they are just
delayed for no apparent reason and ftp and nfs are just impossibly slow.
Neither machine have any load to speak of. And then suddenly things are okay
again. No dropped frames, overruns - nothing wrong has been reported on any
of the two devices (firewall + workstation).
The above problem only pertains to the ASIX cards. Using the Digital card as
one of the two cards handling the communication between the firewall and
workstation works better, no delays, but there are TX errors (carrier) which
brings traffic down to 200-300KB/s, better than nothing I say.
eth0 Link encap:Ethernet HWaddr 00:40:33:9A:DF:92
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:202887 errors:0 dropped:0 overruns:0 frame:0
TX packets:853 errors:367442 dropped:0 overruns:0 carrier:734884
collisions:0 txqueuelen:100
Interrupt:11 Base address:0x6400
--
Perhaps not a real problem, but a little misleading is the fact that both the
Digital and ASIX cards light up the full duplex and 100 MBit LED while
tulip-diag reveals that both cards use half-duplex. Which is it?
tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Digital DS21140 Tulip adapter at 0x6400.
Digital DS21140 Tulip chip registers at 0x6400:
ffa08000 ffffffff ffffffff 00007010 00007210 fc660000 32442002 ffffebef
e0000000 ffffcbf8 ffffffff fffe0000 ffffff60 ffffffff 1c09fdc0 fffffec8
Port selection is MII, half-duplex.
Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 72.
Ethernet MAC Station Address 00:40:33:9A:DF:92.
EEPROM transceiver/media description for the Digital DS21140 Tulip chip.
Leaf node at offset 30, default media type 0800 (Autosense).
CSR12 direction setting bits 0x80.
4 transceiver description blocks:
21140 Non-MII transceiver with media 0 (10baseT).
CSR12 control port setting 00, command 00 0x1d.
Media detection by looking for a 1 on bit 6 of the CSR12 control port.
21140 Non-MII transceiver with media 3 (100baseTx).
CSR12 control port setting 00, command 00 0x8d.
Media detection by looking for a 0 on bit 6 of the CSR12 control port.
21140 Non-MII transceiver with media 4 (10baseT-Full Duplex).
CSR12 control port setting 00, command 00 0x1b.
Media detection by looking for a 1 on bit 5 of the CSR12 control port.
21140 Non-MII transceiver with media 5 (100baseTx Full Duplex).
CSR12 control port setting 00, command 00 0x8b.
Media detection by looking for a 0 on bit 5 of the CSR12 control port.
tulip-diag.c:v1.10 4/12/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a ASIX AX88140 adapter at 0xd400.
ASIX AX88140 chip registers at 0xd400:
00202000 00000000 00000000 0008d010 0008d210 00660000 000ce003 0001abef
00000000 00050000 00000000 00000000 00000100 00000003 00000000 00000000
Port selection is MII, half-duplex.
Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 1024.
The MAC/filter registers are 42ad8000 0000cd91 80000000 00000000.
Ethernet MAC Station Address 00:80:AD:42:91:CD.
EEPROM transceiver/media description for the ASIX AX88140 chip.
Leaf node at offset 30, default media type 0800 (Autosense).
CSR12 direction setting bits 0x00.
1 transceiver description blocks:
Media MII, block type 1, length 12.
MII interface PHY 0 (media type 11).
No MII reset sequence. No MII initialization sequence.
Media capabilities are 7800, advertising 01e1.
Full-duplex map 5000, Threshold map 1800.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
3100 782d 0181 b800 0001 45e1 0003 0000
0000 0000 0000 0000 0000 0000 0000 0000
0640 0018 6800 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000.
Booting the firewall:
tulip.c:v0.91e 5/27/99 becker@cesdis.gsfc.nas a.gov
eth0: Digital DS21140 Tulip rev 34 at 0x6400, 00:40:33:9A:DF:92, IRQ 11.
eth0: EEPROM default media type Autosense.
eth0: Index #0 - Media 10baseT (#0) described by a 21140 non-MII (0) block.
eth0: Index #1 - Media 100baseTx (#3) described by a 21140 non-MII (0) block.
eth0: Index #2 - Media 10baseT-FD (#4) described by a 21140 non-MII (0) block.
eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21140 non-MII (0) block.
eth0: MII transceiver #1 config 1000 status 782d advertising 05e1.
eth0: Advertising 0001 on PHY 1, previously advertising 05e1.
eth1: ASIX AX88140 rev 3 at 0x6500, 00:80:AD:41:F8:54, IRQ 15.
eth1: EEPROM default media type Autosense.
eth1: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
eth1: MII transceiver #1 config 3100 status 782d advertising 05e1.
eth1: Advertising 0001 on PHY 1, previously advertising 05e1.
--
This list is the only place that might answer my problems.
--
Mattias Sandgren - mattias@leif.silicon.nu One of them unix geeks.
Computer Science and Engineering Student - University of Umea, Sweden.
( ( ( ( (( In Stereo Where Available )) ) ) ) )