The NEW Kingston KNE100TX? Reliable?
John Connett
jrc@art.co.uk
Fri Feb 5 05:31:52 1999
We have just received a batch of Kingston KNE100TX cards and on
inspection we found that the design (but not the name) has changed from
a Digital 21140-AF / Intel S82555 combination to an Intel 21143-PD /
SEEQ NQ80220/G combination.
The old KNE100TX cards proved rock solid in operation. In fact we used
them as a work around for a motherboard mounted Digital 21143-PB which
had proved unreliable with earlier versions of the tulip driver (mainly
auto-negotiation problems with different flavours of hub and switch).
Is this new KNE100TX likely to be reliable with the current stable
version (v0.90) of the tulip driver?
Would the motherboard mounted Digital 21143-PB be more (or less)
reliable than the new KNE100TX cards with the v0.90 tulip driver?
We really need a solution that is as reliable as the old KNE100TX and if
the new version isn't it we will need to identify an alternative pretty
quickly!
In a message to this mailing list on Tue, 12 Jan 1999 Tue, Steve Morvai
(morvai@synerworks.com) mentioned an Intel document that "mentions the
register level differences between the 21143xC and 21143xD chip
revisions" and implies that a fix will be required to the driver to
support the new chip.
An initial test of the new KNE100TX with a 2.0.36 Alpha kernel and a
built-in (non-module) driver appears to work and gives the following
output during boot:
tulip.c:v0.90 10/20/98 becker@cesdis.gsfc.nasa.gov
[eth0 text removed]
eth1: Digital DS21143 Tulip at 0xa800, 00 c0 f0 3b 39 94, IRQ 27.
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 3000 status 7829 advertising 01e1.
The relevant portion of /proc/pci contains the following:
Bus 1, device 10, function 0:
Ethernet controller: DEC DC21142 (rev 65).
Medium devsel. Fast back-to-back capable. IRQ 27. Master
Capable. Latency=32. Min Gnt=20.Max Lat=40.
I/O at 0xa800.
Non-prefetchable 32 bit memory at 0x9300000.
If any other information would be useful, please let men know and I will
try to obtain it.
Thanks in anticipation
--
John Connett (jrc@art.co.uk)