is 21143/MII a PNIC 21142 rtl8139

[Bill Paul]

Bob (recbo@erols.com) writes:

>   Even a telepathic helmet can't help if we blink and miss  
>   the "+" at the end of the model number, indicating it is
>   now an rtl8139 instead of a 21143.
        
>   Of course that was really a 21142 "21143". Shouldn't
>   21142's go in the trash can?

Actually, in this case it really was a 21143. Kurt's follow-up mail
said:

>           21143-PD
>           DC1096B
>           S 9910 JK 4696
>           INTEL (May this be the problem?) (M)(C) 1997

I have cards with 21143-xD chips and 21143-xC chips. The xD chips
tend to say Intel on them while the xC ones still say Digital. However
both seem to work the same with the driver that I wrote (for FreeBSD).

>   I did a lot of searching today to find out which cards
>   have a real 21143 with MII, or even which one card
>   does. That should be an FAQ, although one vendor
>   added a "+" to the old number, slipping in an rtl8139,
>   so keeping up the FAQ with such tricks going on
>   would be a project.

Sometimes even the vendors can't keep track. When I started development
on my driver, I needed sample cards that I could test. I found the
Kingston KNE100TX (kay enn eee one hundred tee ecchs), which I knew used
the 21143 chip, and ordered it. When the box arrived, I opened it and
found that the distributor had actually sent me a KNE110TX (kay enn eee
one-ten tee ecchs) which is a PNIC 82c169 card. The invoice clearly said
KNE100TX though. Not only did the board have the wrong chipset, I was
charged the wrong price: the KNE110TX is less expensive than the KNE100TX,
so I had been shafted by about $15 or so. I did get the card exchanged
eventually though, so it worked out in the end, but it was still a little
frustrating. (And it set back my development schedule by a few days.)

Naturally, when you confront the vendors with issues like this, they
all suddenly get the same "deer caught in the headlights" look and
try to give you the same hackneyed excuse. "But what's the difference;
they both work with Windows, so they must be the same, right?" Bleh.

Kurt's original problem still stands, however. If even 0.91g still
produces cruddy performance after negotiating a 100Mbps full-duplex
link, then there's a bug somewhere. I ran into this exact problem when
developing the if_dc driver for FreeBSD: I was using a DEC DE500-BA
card and an Intel switch: both claimed to have negotiated a 100mbps
full duplex link, yet the interface stats still indicated collisions.

I fixed this in the media handling code by turning off the "autoneg
enable" bit in CSR14 as soon as the NWAY had completed and the driver
had read the link partner capabilities word. You should be able to
do the same with the tulip driver. In fact, I can give you a small
patch for it. However I can't easily test it as I don't have a Linux
box to try it with myself.

Anyway, here's what you can do:

1) Get tulip.c version 0.91g.
2) Locate the t21142_lnk_change() function. It's right after the
   t21142_start_nway() function.
3) Find the block of code that looks like this:

        /* If NWay finished and we have a negotiated partner capability. */
        if (tp->nway  &&  !tp->nwayset  &&  (csr12 & 0x7000) == 0x5000) {
                int setup_done = 0;
                int negotiated = tp->to_advertise & (csr12 >> 16);
                tp->lpar = csr12 >> 16;
                tp->nwayset = 1;
                if (negotiated & 0x0100)                dev->if_port = 5;
                else if (negotiated & 0x0080)   dev->if_port = 3;
                else if (negotiated & 0x0040)   dev->if_port = 4;
                else if (negotiated & 0x0020)   dev->if_port = 0;
                else {
                        tp->nwayset = 0;
                        if ((csr12 & 2) == 0  &&  (tp->to_advertise & 0x0180))
                                dev->if_port = 3;
                }
                tp->full_duplex = (media_cap[dev->if_port] & MediaAlwaysFD) ? 1:0;

   This code starts at line 2120 and ends at line 2135.

4) At line 2136, add the following lines of code:

#define TULIP_CLRBIT(reg, x) outl(inl(ioaddr + (reg)) & ~(x), ioaddr + (reg))
#define DC_TCTL_AUTONEGENBL     0x00000080
                TULIP_CLRBIT(CSR14, DC_TCTL_AUTONEGENBL);

5) Recompile the driver and test it: let the driver autonegotiate with
   the switch and see what it does.

Kurt: if you try this, I'd be interested to know the results.

-Bill

-- 
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul@ctr.columbia.edu | Department of Electrical Engineering
Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"Mulder, toads just fell from the sky!" "I guess their parachutes didn't open."
=============================================================================