[tulip] anyone get danpex afp1100 to do fdx?
Thu, 29 Mar 2001 17:01:06 -0500 (EST)
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
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 <firstname.lastname@example.org>
> 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 email@example.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993