Determining eepro100's negotitated mode

[Donald Becker]

[[ Quick status update for the eepro100 list:
   I will soon release driver v1.08 with PowerPC support.
   Avoid using the driver in recent v2.2.* kernels -- someone has added an
   SMP lock in the driver structure that misaligns the descriptors,
   resulting in a much increased likelyhood of the chip errata that causes
   some transmit timeouts. ]] 

On Tue, 4 May 1999, Andrew M. Kuchling wrote:

> >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:
...
>  Link partner capability is 0081: 100baseTx.
>    Negotiation did not complete.

This means that the remote machine, your link partner, does not do
autonegotiation.  This transcevier goes beyond the minimal specification and
reports that 100baseTx link beat exists.  (There are some bad transceivers
that don't report this.)

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

It's pretty simple -- the remote machine doesn't have autonegotiation
enabled.


Donald Becker					  becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882	     http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html