Problem with full duplex or MII with DEC 21143
Sun Nov 1 03:29:00 1998
Still no success on getting this CNET CN100TX to work at full
duplex - it seems to be half duplex or not at all. I will try
swapping out the null modem cable with one that is known to be
o.k. Also, I ordered a few more of these cards, and will swap
out the cards in case there is a hardware problem (one of them
has acted suspicious, but all these ethernet cards act suspicious...)
Other than that I don't know what else to try. options=5 did not work.
Both machines have 2.0.35 kernel.
Is there a way to restart the autonegotiation process? I suppose
unplugging the cable does this; I've tried this as well. However, these
cards seem to occasionally get stuck in configurations, it seems to me.
It might be nice to "restart" autonegotiation by software.
I wonder about spending all this time to get a stupid $15 card to
On Sat, 31 Oct 1998, Donald Becker wrote:
> On Sat, 31 Oct 1998, Brian Dushaw wrote:
> > I have a pair of DEC 21143 cards connected via a null modem
> > cable. These work fine at 100baseTX, except that I can't
> > get full duplex to enable.
> They should autonegotiate full duplex themselves.
> You should only force full duplex when working with old-style equipment,
> typically Cisco switches, that does not autonegotiate.
> > I can set options=14, in which
> > case full duplex is reported by tulip-diag, but then the
> > cards will not communicate.
> Media type 14 is MII-full duplex. Your board likely does not have a MII
> transceiver and is instead using the internal symbol mode transceiver.
> The internal transceiver has a badly designed autonegotiating feature,
> overloading the full-duplex advertising capability bit with the full-duplex
> setting in CSR6. (Grrr... all other advertising bits are cleanly grouped
> except of this one. The 21143 is not nearly as clean of a design as the
> original chips.) This might be confusing 'tulip-diag', which cannot see
> the internal state of the chip.
> > I have tried a variety of options,
> > (including no options) and a variety of driver versions (0.88 0.89L 0.90
> > etc) all to no avail. Any ideas?
> Use no option, and just measure the bidirectional bandwidth.
> If you must try an media option, use media type '5'.
> > A related problem may be that MII appears not to be recognized.
> > dmesg reports:
> This means your board does not use an MII transceiver.
> Most recent boards do use MII, since MII transceiver are now less expensive,
> but the 21143 is designed to use SYM PHYs (symbol mode physical layer).
> The MII PHY vs SYM PHY issues, and the many ways to connect a SYM PHY, is
> a reason the Tulip is so difficult to write a driver for. It's easy to
> support only a single board type, as board vendors have the luxury of doing.
> It's far more complicated to support all board types.
> > tulip.c:v0.89L 10/9/98 firstname.lastname@example.org
> > eth1: Digital DS21143 Tulip at 0xc000, 00 80 ad 22 13 53, IRQ 10.
> > eth1: EEPROM default media type Autosense.
> > eth1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2)
> > block.
> > eth1: Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY
> > (2) block.
> > eth1: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4)
> > block.
> > eth1: Index #3 - Media 100baseTx-FD (#5) described by a 21143 SYM PHY (4)
> > block.
> This is exactly the media table from the Digital design kit.
> That means it's either a generic design, or the vendor just didn't bother to
> change it to reflect what the board actually does.
> > These were $15 cards, so perhaps I am paying for this now....
> > The card is CNET CN100TX, it advertises full duplex capability.
> That's a good price. Where did you get them?
> Donald Becker email@example.com
> 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