[tulip-bug] Re: tulip.c vs ANA6944TX

[Donald Becker]

On Wed, 2 Aug 2000, Christopher E. Brown wrote:

> To: linux-tulip@beowulf.org, linux-tulip-bug@beowulf.org,
>    linux-kernel@vger.rutgers.edu, linux-net@vger.rutgers.edu

You should limit this to linux-tulip or linux-tulip-bug (aliases for
tulip@scyld.com and tulip-bug@scyld.com), unless it's a problem with the
pre-2.4 code in which case linux-kernel@vger.rutgers.edu is appropriate.

> Subject: tulip.c vs ANA6944TX

I no longer have access to one of these (they moved to Michigan with a large
cluster), but the versions I had worked fine in previous tests.

> 	I have a very strange issue with the tulip 21140 based
> ANA6944TX quad 10/100 ethernet card.  We were using the cards for some
> time, but as of late 1999 they stopped working with most MBs they were
> tried with, in one case with 2 identical Tyan S1590S boards, same rec,
> bios, setting, CPU and cards 1 worked one didn't.

That's very curious.

> Symptoms are, board inits fine, no errors, everything looks correct,
> but NWAY autoneg does not function, sometimes port will be usable in
> 10Mbit HD, sometime repeated resets with tulip-diag will cause port to

This is caused by the transceiver initial setting.
    > eth0:  Advertising 01e1 on PHY 1, previously advertising 0101.
This has the transceiver only advertising 100baseTx-HD at power-up!
The transceiver's pins are normally wired so that it advertises all
capabilities.

Please try running 'mii-diag' from
  http://www.scyld.com/diag/index.html

Reset the transciver, and check its state
  mii-diag eth0 -R; mii-diag eth0
Advertise everything, and check the state
  mii-diag eth0 -A 0x01e1; mii-diag eth0

> function for a short period.  With some mainboards, ports 1 and 3 or 2
> and 4 will function, but erraticly.  Passing options= params to

This is likely caused by a IRQ mapping bug common in x86 BIOSes.
PCI Chips behind a bus bridge are marked having different IRQs, even though
they are all mapped to the same IRQ.
The driver source has details, and the work-around.

> tulip.o does nothing.  Attempting to pass traffic after configuring an
> interface results in (IIRC) neighbor table overflow messages

Yup, that's not a very informative message.  No my fault.

> tulip.c:v0.92 4/17/2000  Written by Donald Becker <becker@scyld.com>
>   http://www.scyld.com/network/tulip.html
> eth0: Digital DS21140 Tulip rev 34 at 0xc4853f80, 00:00:D1:1F:1E:34, IRQ 10.
> eth0:  EEPROM default media type Autosense.
> eth0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> eth0:  MII transceiver #1 config 3100 status 7849 advertising 0101.
> eth0:  Advertising 01e1 on PHY 1, previously advertising 0101.

This is the previously mentioned problem with the bogus initial type
advertising.

> mii-diag.c:v1.07 10/14/99  Donald Becker (becker@cesdis.gsfc.nasa.gov)
>  MII PHY #1 transceiver registers:
>    3100 7849 2000 5c01 01e1 0000 0010 0000
..
>  Basic mode status register 0x7849 ... 7849.
>    Link status: not established.

No link beat.  Try the reset above.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403