New LinkSys CardBus vs. Old LinkSys CardBus

[Donald Becker]

On Wed, 23 Dec 1998, Nathan Anderson wrote:

> Subject: New LinkSys CardBus vs. Old LinkSys CardBus
> I have two LinkSys EtherFast CardBus PC Cards that I'm playing around
> with trying to get working under Linux on my ThinkPad 770.
..
> They both appear to be 21143-based cards.  At least I /think/ they both
> are.

Yes, but two different versions of the 21143.  There are seven or eight
different chip revisions of the 21143.  Many of the changes are minor, but
the new 'TD' chip changes the EEPROM initialization of the CardBus registers
substantially.

>  Perhaps one is a 21142-based card?

The 21142 and 21143 have the same chip ID number, but few 21142 chips were
made.  Think of the 21142 as just an early 21143.

> 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.

It's much easier to write a backwards-compatible driver than one that
predicts future hardware changes ;->.

>  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


> 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.

It works that with my sample card as well.  I don't know how the LEDs are
wired.

>  With the special PCMCIA-revision of 0.89
> (0.89L), the lights act normally and the card appears to work okay

!! I'll check that out.  The drivers should behave identically.

> 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.

Yes.  The dongle appears to contain some vital circuitry that must exist
when the card is powered up.  If the dongle isn't plugged in, the MII
transceiver isn't detected.  Since the EEPROM on many cards is wrong, the
driver relies on detecting the MII transceiver to switch into MII mode.

A driver designed to work only with the LinkSys card will not have this
problem, since it just "knows" the transceiver connection is MII and ignore
the incorrect EEPROM table.

> On the second card, the lights work as expected with either driver
...
> 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.

This is the 'TD' card, with a larger EEPROM.
I don't have one to test with, but please try the following change to line
391:

-#define EEPROM_ADDRLEN 6
+#define EEPROM_ADDRLEN 8

This should allow the driver to work, but only with the 'TD' card!
Please send a report.
If this works correctly, I can change the driver to use the chip revision
number to select the EEPROM_ADDRLEN value.
(Note the added code in 0.90f to prepare for this.)

> 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."

This is likely a hardware or CardBus controller setup issue.
Does it happen with other OSes?

Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html