[tulip] anyone get danpex afp1100 to do fdx?

[Donald Becker]

On Fri, 23 Mar 2001, Leo Wierzbowski wrote:

> After many reboots I've discovered that the newer model will sometimes
> go into FDX with options 0x20b.  When it does so, tulip identifies the
> NIC similarly as the old model (Media MII described by a 21142).  When
> it doesn't, the message below appears, and this is the normal case for
> 0x20b (and is always the case when I specify the MII media type or try
> any other combo of anything):

Please clarify this.
Do you mean that the detection message changes between reboots?
If so, that indicates that the EEPROM read is somehow unreliable.

The v0.92t driver has a change from the earlier driver versions to add
extra turn-around time when reading the EEPROM.  This was for a specific
card model with slow EEPROMs, and only occurred with 600Mhz+ machines.
The symptom was that the high bit of some EEPROM words incorrectly read
as set. (0x0000 was read as 0x8000.)  Your problem seem to be slightly
different -- a random high bit flip.

> > > Tulip reports on boot up:
> > > Index #0 - Media MII 100baseTx (#13) described by a 21140 non-MII (0) block.
> > Ohhhh, that's bad.  That appears to be an invalid media table entry.
> > Please send the output of 'tulip-diag -ee' so that we can see the raw
> > entry.

> Index #2: Found a Digital DS21143 Tulip adapter at 0xe800.
...
> PCI Subsystem IDs, vendor 146c, device 1430.
> CardBus Information Structure at offset 00000000.
> Ethernet MAC Station Address 00:40:C7:AA:02:D7.
> EEPROM transceiver/media description table.
> Leaf node at offset 30, default media type ffff8800 (Autosense).

Hmmm, 0xffff8800.  That's a sign-extension buglet in the tulip-debug
code...fixed. 

The important detail is that this value would normally be 0x0800, not
0x8800.  0x8800 is a valid value that means "power-up autosense only",
but that setting is not normally used. We might be seeing the EEPROM
read corruption mentioned above.

>  1 transceiver description blocks:
>     Media capabilities are 6000, advertising 0181.

This is unusual: the transceiver is limited to advertising only
100baseTx and 100baseTx-FDX media types.  

>     MII interrupt on GPIO pin -1.

???  This indicates that the MII transceiver is removable: it's an
external transceiver, plugged into the adapter.  Is that correct?  I've
not seen a PCI board where this is true.

>  MII PHY #1 transceiver registers:
>    3100 782d 0302 d008 01e0 0080 0004 2801

It's very likely not true if the MII transceiver is at address #1
instead of #0.  And this transceiver is reporting that it can do 10+100.

> EEPROM contents (64 words):
> 0x00:  146c 1430 0000 0000 0000 0000 0000 0200
> 0x08:  48fd 0104 4000 aac7 d702 1e00 0000 8800
> 0x10:  8d01 0003 0000 6000 0180 4000 0000 0080
> 0x18:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x20:  0000 0000 0000 0000 0000 0000 0000 0000
> 0x28:  0000 0000 0000 0000 0000 0000 0000 e151
> 0x30:  0000 0000 0000 4000 aac7 d702 0040 0000
> 0x38:  0000 0000 0000 0000 0000 0000 0000 000f

Hmmm, interesting: this EEPROM has magic packet information.  I've
recently updated the tulip-diag program to handle the new format and
emit some of the magic packet control information.

> Mar 23 12:49:45 gatorouter kernel: tulip.c:v0.92 4/17/2000  Written by
> Donald Becker <becker@scyld.com> 
...
> Mar 23 12:49:45 gatorouter kernel: eth1: Digital DS21143 Tulip rev 65 at
> 0xc4865800, 00:40:C7:AA:02:57, IRQ 11.

Hmmm, first indication of a problem -- the station address is very
slightly wrong.  ...:02:57 instead of ...:02:d7.

Please try v0.92t to see if the problem is corrected.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993