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

[Christopher E. Brown]

On Wed, 2 Aug 2000, Donald Becker wrote:

> On Wed, 2 Aug 2000, Christopher E. Brown wrote:
> > 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.

	These are REV C cards, seem to have come out in early to mid
1998 - EOL

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

	I think the earlier units were Rev A and Rev B.  Cannot verify
as I no longer have them.

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


	I have tulip-diag and mii-diag from said location.  Have used
both -r and -R, sometimes, after multiple resets and cable
plug/unplug, it will report as an MII and and interface will go live.


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

	I was under the impression the Rev A cards did this, but the
Rev C and *maybe* Rev B cards do not hardwire the IRQs to that of the
first iface.

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

	I know, just trying to include everything while going into my
38th hour at work.

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

	Have done so, mentioned above.  No option or attempt with the
tools results in a workable card.

	My understanding is that IRQ handing changed between revs, and
that the A, B, and C rev cards all use slightly differend models of
MII transciever.


	If you wanted to tackel this I should be able to loan you a
Rev C ANA6944TX for at least a couple of months.


---
As folks might have suspected, not much survives except roaches, 
and they don't carry large enough packets fast enough...
        --About the Internet and nuclear war.