[tulip] No MII transceiver found

[Jarl Friis]

Hi.

Donald Becker <becker@scyld.com> writes:

> On 5 Dec 2002, Jarl Friis wrote:
> 
> > Donald Becker <becker@scyld.com> writes:
> > > On 3 Dec 2002, Jarl Friis wrote:
> > > > Hi, just downloaded netdrivers-3.3, system is otherwise SuSE 8.1
> > > > 
> > > > I can't get my NetGear FA510 PCMCIA to work, I have tried the tulip dirver
> > > > with debug=2 and among other things I get 
> > > > Dec  3 19:26:59 hermes kernel: eth0: ***WARNING***: No MII transceiver found!
> ..
> > FYI: tulip-diag is compiled with libmii and libflash and gcc 3.2 some warnings showed up, are you interested in those?
> 
> What were the warnings?  Are there any besides the bogus "inl() returns
> long" messages?  (Grrrr... kernel idiots.)

Nothing important, here is the result:
-------------------------------------
cd /tmp/net-diag/
cc -O -Wall -Wstrict-prototypes -o tulip-diag tulip-diag.c `[ -f libmii.c ] && echo -DLIBMII libmii.c` `[ -f libflash.c ] && echo -DLIBFLASH libflash.c`
tulip-diag.c:40:1: warning: multi-line string literals are deprecated
tulip-diag.c:1391:24: warning: multi-line string literals are deprecated
tulip-diag.c:1677:1: warning: multi-line string literals are deprecated
tulip-diag.c:1683:1: warning: multi-line string literals are deprecated

Compilation finished at Sat Dec  7 00:18:16
---------------------------------------------

> > Here is the output of tulip-diag -eee -m -a:
> > 
> > tulip-diag.c:v2.15 9/23/2002 Donald Becker (becker@scyld.com)
> ...
> > EEPROM transceiver/media description table.
> >   Media MII, block type 3, length 13.
> >    MII interface PHY 0 (media type 11).
> >    21143 MII initialization sequence is 0 words:.
> >    21143 MII reset sequence is 0 words:.
> 
> Hmmm, nothing special needs to be done for this transceiver.  It should
> just work.
> 
> >  MII PHY found at address 1, status 0x7849.
> >   Internal autonegotiation state is 'Autonegotiation disabled'.
> 
> And it is working here!!  You can verify with 'tulip-diag -mm'.
> Could you please send that output?

Here is the output:
-----------------------------------------
tulip-diag.c:v2.15 9/23/2002 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a Digital DS21143 Tulip adapter at 0x4000.
 Port selection is 10mpbs-serial, half-duplex.
 Transmit stopped, Receive stopped.
  The Rx process state is 'Stopped'.
  The Tx process state is 'Stopped'.
  The transmit threshold is 72.
  The NWay status register is 000020c7.
 MII PHY found at address 1, status 0x786d.
 MII PHY #1 transceiver registers:
   1000 786d 0043 7421 01e1 40a1 0001 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0230 0087 0000 0000 0000 0000 c4c8 0600
   0000 0421 2010 2000 8000 0000 0000 0000.
 Basic mode control register 0x1000: Auto-negotiation enabled.
 Basic mode status register 0x786d ... 786d.
   Link status: established.
   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Vendor ID is 00:10:dd:--:--:--, model 2 rev. 1.
   No specific information is known about this transceiver type.
 I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
   Advertising no additional info pages.
   IEEE 802.3 CSMA/CD protocol.
 Link partner capability is 40a1: 100baseTx 10baseT.
   Negotiation  completed.
  Internal autonegotiation state is 'Ability detect'.
------------------------------------------------

Now, how should that look for a working adapter?

> > > The "rev 65" makes me believe that this is really a 211143.
> > Has this "rev 65" anything to do with the "rev 41" in the lspci?
> 
> Same number, 0x41 == 65 decimal.
> The 'lspci' output doesn't prepend a 0x to the hexadecimal number.

Ah, of course, I should have known the Hexadecimal numbers good enough
to recognise this. ;-)

I really appreciate your time.

Jarl