New LinkSys CardBus vs. Old LinkSys CardBus
Nathan Anderson
nathana@premier1.net
Wed Dec 23 17:11:00 1998
Hey!
I'm kinda new at this ethernet thing, and don't understand all of the
particulars, so I would appreciate some enlightenment. :-) Be warned!:
This post, like most of my posts [;-)], is lengthy, but only because I
strive to acurately describe the situation and all of the details I know
about it. Hopefully this post fulfills my goals, and hopefully I
provide enough details so that an accurate diagnostic can be performed.
I have two LinkSys EtherFast CardBus PC Cards that I'm playing around
with trying to get working under Linux on my ThinkPad 770. One is going
back, and I need to know which one. They both /almost/ work, and each
one has its own different set of quirks. Both, I have found out, are
physically different from each other, even though they bear the same
model number and FCC ID number!
They both appear to be 21143-based cards. At least I /think/ they both
are. Perhaps one is a 21142-based card? It's interesting because the
Windows driver disk that came with the newer (second) card I just got
works with both cards, but the older Windows drivers only work with the
first card. The driver revision log indicates that this is the only
thing that has changed from version 1.0 to 2.0 of the Windows drivers:
Version 2.00
support 21143 TD
What's a 'TD'? Could this log possibly mean that 2.00 supports 21143
now whereas the older driver supported the 21142 chipset?
Anyways, onto the problems I've had in Linux.
On the first (older) card, I tried the "stable" version of tulip 0.90.
It worked, for the most part. The one oddness with this particular
card/driver version combination is that, even though it works (i.e., it
can communicate over my 10B-T hub to another machine), the link light
and 100Mbit lights on the dongle are /always/ on, even when there is no
link (hub is off or I disconnected it from the card) and even though it
is not a 100Mbit connection. With the special PCMCIA-revision of 0.89
(0.89L), the lights act normally and the card appears to work okay
(except for one other problem common to both cards, which I will get to
in a second). The latest test version of the driver, 0.90F, does not
fix the indicator lights. That broke somewhere between 0.89 and 0.90.
The final weird problem I am experiencing with this card is that /unless
the dongle is connected to the card/, I get:
eth0: The transmitter stopped! CSR5 is f0068002, CSR6 b3860002.
a few seconds after initialization. If, after that, I plug the dongle
in and then plug the card into my hub, I find that the card is sending a
constant stream of something, and the hub's collision light is
constantly on. Taking out the card an putting it back in (with the
dongle firmly attached) will allow the card to work again.
On the second card, the lights work as expected with either driver
versions. However, I can't get this card to work under Linux at all.
On this card, I get the same "transmitter stopped" error as above (with
same values shown for CSR5 and CSR6) whether the dongle is connected or
not. The other strange thing about this card is that the tulip driver
is not extracting the correct MAC address from this card. The address
is always shown to be 00:80:00:80:00:80.
The problem that is common to both cards is that both of them
occasionally (and randomly) lock up the machine. Hard. One time (and
only once) was a message displayed on the console before a lockup. I
have not seen it happen since on subsequent lockups. The message said,
"Unknown interrupt."
Under Windows, both cards work as expected.
So, obviously both cards are different. But just how different? To
find out, I downloaded the complete set of Linux tulip diagnostic tools,
and built myself a tulip-diag with libmii. I executed tulip-diag on
each card with the options '-e -e -a -m -m -v'. Here's the output I got
for the first card:
tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Digital DC21040 Tulip Tulip chip registers at 0x280:
ffa04800 ffffffff ffffffff 00e94028 00e94228 f0000102 b20e0000
f3fe0000
e0000000 fffd83ff ffffffff fffe0000 000000c6 ffff0000 fff80000
8ffb0008
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
Transmit stopped, Receive stopped, half-duplex.
The transmit threshold is 128.
Port selection is MII, half-duplex.
EEPROM contents:
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ID CRC 0xfa (vs. 0xff), complete CRC 57a987a3.
MII PHY found at address 0, status 0x7809.
MII PHY #0 transceiver registers:
1000 7809 7810 0001 01e1 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 4000 0000 042b 0010 0000 0002
0001 0000 0000 0000 0000 0000 0000 0000.
Basic mode control register 0x1000: Auto-negotiation enabled.
Basic mode status register 0x7809 ... 7809.
Link status: not established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 1e:04:00:--:--:--, model 0 rev. 1.
Vendor/Part: Level One LXT971.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0000:.
Negotiation did not complete.
And the output for the second, newer card:
tulip-diag.c:v1.06 9/18/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Digital DC21040 Tulip Tulip chip registers at 0x280:
f9a04800 ffffffff ffffffff 00fff820 00fffa20 f0000102 b3860000
f3fe0000
e0000000 fffc83ff ffffffff 00000000 000000c6 ffff0001 fffbff7f
8ffb0008
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
Transmit stopped, Receive stopped, half-duplex.
The transmit threshold is 128.
Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex.
EEPROM contents:
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
ID CRC 0xfa (vs. 0xff), complete CRC 57a987a3.
MII PHY found at address 0, status 0x7809.
MII PHY #0 transceiver registers:
3000 7809 0040 6212 01e1 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0220 0220 0000 0001 0000 0000 0100 0000
003c 1002 0f00 ff00 002c 0000 0010 000b.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x7809 ... 7809.
Link status: not established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 00:10:18:--:--:--, model 33 rev. 2.
No specific information is known about this transceiver type.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0000:.
Negotiation did not complete.
Okay, so, it appears that one of the differences between the two cards
is that they both have different transceivers (whatever that be?). The
transceiver in the second card is not recognized by tulip-diag.
Also, what is "Port selection"? They both are set to different "port
selections". Does that have to do with the transceiver as well? The
older card says it is set to "MII". The newer card is set to
"100mbps-SYM/PCS 100baseTx scrambler". What's the difference?
Also, here are the different startup messages I get with each card.
First, the older:
kernel: tulip.c:v0.89L 10/9/98 becker@cesdis.gsfc.nasa.gov
kernel: eth0: Digital DS21143 Tulip at 0x280, 00 e0 98 02 21 d2, IRQ 3.
kernel: eth0: EEPROM default media type Autosense.
kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial
PHY (2) block.
kernel: eth0: Index #1 - Media 10baseT-FD (#4) described by a 21142
Serial PHY (2) block.
kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM
PHY (4) block.
kernel: eth0: Index #3 - Media 100baseTx-FD (#5) described by a 21143
SYM PHY (4) block.
kernel: eth0: MII transceiver #0 config 1000 status 7809 advertising
01e1.
And now, the newer one:
kernel: tulip.c:v0.89L 10/9/98 becker@cesdis.gsfc.nasa.gov
kernel: eth0: Digital DS21143 Tulip at 0x280, 00 80 00 80 00 80, IRQ 3.
kernel: eth0: EEPROM default media type 10baseT.
The second one isn't programmed to autodetect? Is that what that
means? Also, does the first card have an MII while the second one
doesn't?
I was also reading up on Donald's explanation on the differences between
the 21142 chipset and the 21143 chipset. He says the following:
"While most PCI board designs have switched over to using MII
transcievers, CardBus power limitations and agressive cost reductions
have made it advantageous to once again use the simplier SYM
transceivers."
So, I guess what the ultimate question is, which card is the better
card? Which card should I keep? If it really is that my second card is
"cheaper" as a result of "agressive cost reductions", then I'm assuming
the first card is the one I should choose. I'm just not clear on what
the real differences are between the two cards, and why I'm having so
much trouble with both of them.
In the quest to get either (or both) cards working with the Linux
drivers, I'd be more than happy to give any additional information you
may require, or run any additional tests you may need me to make. Even
the card I do decide to return I would like to get working under Linux
so that others who purchase a newer LinkSys CardBus ethernet card can
get theirs working under Linux.
I would also like to take this moment to publicly thank Donald Becker
and others who have worked on this driver. The new 0.90 now drives my
new PCI Macronix-based cards perfectly. Haven't had the
"duplicate-packets" problem since 0.90 that others have talked about.
Thanks!
-- Nathan Anderson 16 yrs old
<mailto:nathana@premier1.net>