[tulip] D-Link DFE-570TX card works 3/4

Andreas Trottmann andreas.trottmann@werft22.com
Wed, 21 Mar 2001 17:39:54 +0100


Hi!

We just bought a D-Link DFE-570TX "quatruple NIC" card for use in a server. 
Unfortunately, we experienced a problem with it which (after searching
the mailing list archives) seems to be quite unique.

Basically, the first NIC of the card (corresponding to the topmost port)
acts very strange, while the other three NICs work fine.

When booting 2.2.18 with the tulip driver, we get

eth0: Digital DS21143 Tulip rev 65 at 0xcc80, EEPROM not present, 00:4C:69:6E:75:79, IRQ 11.
eth0: Old style EEPROM with no media selection information.
eth1: Digital DS21143 Tulip rev 65 at 0xcc00, 00:80:C8:CA:5C:D4, IRQ 10.
eth1:  EEPROM default media type Autosense.
eth1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
eth1:  MII transceiver #1 config 3100 status 7849 advertising 01e1.
eth2: Digital DS21143 Tulip rev 65 at 0xc880, 00:80:C8:CA:5C:D6, IRQ 9.
eth2:  EEPROM default media type Autosense.
eth2:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
eth2:  MII transceiver #1 config 3100 status 7869 advertising 01e1.
eth3: Digital DS21143 Tulip rev 65 at 0xc800, 00:80:C8:CA:5C:D7, IRQ 5.
eth3:  EEPROM default media type Autosense.
eth3:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
eth3:  MII transceiver #1 config 3100 status 7869 advertising 01e1.

note that "eth0" (corresponding to the first NIC / the topmost port)
gives a very different HW address and very different EEPROM information.
When connecting this port to a hub, the hub acts very strangely (a
"noname" hub we tried only flashes the link LED in red, while a
CentreCom FH716SW randomly turns on the "partition" LED of the affected
port).

We also periodically get messages like these:

eth0: Tx hung, 11 vs. 0.
eth0: 21140 transmit timed out, status f0660005, SIA 000000c6 ffff0001 fffbff7f 8ff0c008, resetting...
eth0: Tx hung, 11 vs. 0.
eth0: 21140 transmit timed out, status f0680187, SIA 000000c6 ffff0001 fffbff7f 8ff0c008, resetting...
eth0: Tx hung, 15 vs. 0.
eth0: 21140 transmit timed out, status f0000187, SIA 000010c6 ffff0001 fffbffff 8ff0c008, resetting...
eth0: Tx hung, 15 vs. 0.

and so on.

It is impossible to use eth0 for any network connectivity. Meanwhile,
eth1, eth2 and eth3 are working fine.



For curiosity, we tried the same hardware with 2.2.18 and the de4x5
driver. This one gives

eth0: DC21143 at 0xcc00 (PCI bus 2, device 5), h/w address 00:80:c8:ca:5c:d4,
      and requires IRQ10 (provided by PCI BIOS).
de4x5.c:V0.544 1999/5/8 davies@maniac.ultranet.com
eth1: DC21143 at 0xc880 (PCI bus 2, device 6), h/w address 00:80:c8:ca:5c:d6,
      and requires IRQ9 (provided by PCI BIOS).
de4x5.c:V0.544 1999/5/8 davies@maniac.ultranet.com
eth2: DC21143 at 0xc800 (PCI bus 2, device 7), h/w address 00:80:c8:ca:5c:d7,
      and requires IRQ5 (provided by PCI BIOS).
de4x5.c:V0.544 1999/5/8 davies@maniac.ultranet.com

note that this one does not seem to "see" the malfunctioning NIC at
all: what de4x5 configures as eth0 is the second NIC (which was
configured as eth1). Again, we can use these three of the four NICs of this 
card.


My questions are: 

Has anyone seen such a behaviour before?

Can this behaviour be a result of some misconfiguration on our part, or
of some bug in the tulip and/or de4x5 driver?

Or is one of the four DC21143 chips on our card simply broken, and we
should ask the supplier for a replacement?


thanks a lot for your help!


-- 
Andreas Trottmann <andreas.trottmann@werft22.com>