Determining eepro100's negotitated mode

[Andrew M. Kuchling]

Donald Becker writes:
>The negotiated ability is the highest common mode.  In this case it's
>100baseTx-FD.
>
>Details of how this occurs is in
>  http://cesdis.gsfc.nasa.gov/linux/misc/NWay.html

	Thanks for your quick response.  Changing the card's mode
works fine on the system located here at CNRI, but negotiation isn't
completing on the remote system.  Here's the failing mii-diag invocation:

[/tmp]# ./mii-diag  -A 100baseTx    
Using the default interface 'eth0'.
 Setting the media capability advertisement register of PHY #1 to 0x0181.
 MII PHY #1 transceiver registers:
   1000 782d 02a8 0150 0181 0081 0000 ffff
   ffff ffff ffff ffff ffff ffff ffff ffff
   0a02 0000 0001 0000 0000 0000 0000 0000
   0000 0000 d0cd 0000 ffff ffff ffff ffff.
 Basic mode control register 0x1000: Auto-negotiation enabled.
 Basic mode status register 0x782d ... 782d.
   Link status: established.
   Capable of  100baseTx-FD 100baseTx 10baseT-FD 10baseT.
   Able to perform Auto-negotiation, negotiation complete.
 Vendor ID is 00:aa:00:--:--:--, model 21 rev. 0.
   No specific information is known about this transceiver type.
 I'm advertising 0181: 100baseTx-FD 100baseTx
   Advertising no additional info pages.
   IEEE 802.3 CSMA/CD protocol.
 Link partner capability is 0081: 100baseTx.
   Negotiation did not complete.
[/tmp]# 

The link seems to be capable of capabilities that match the card's,
but the negotiation doesn't complete.  Presumably the card is then
placed into some safe fallback mode, because the machine is still
accessible despite the failure.  How do I determine the cause of the
failure?

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Ha -- you have done me the favor of underestimating my ignorance <smile>.
    -- Tim Peters, 30 Dec 91