[vortex] 3C905TX doesn't see 10Mbps hub till unplugged/replugged

[Donald Becker]

On Fri, 23 Jun 2000, Bogdan Costescu wrote:

> On Thu, 22 Jun 2000, Donald Becker wrote:
> 
> > Doing 'mii-diag -R' will reset the transceiver, retriggering
> > autonegotiation.
> 
> The original post mentioned that even only 'mii-diag -F 10base-T' worked,
> so no need for resetting the transceiver, just forcing it to the right
> speed (I'm assuming that this forcing does not reset the transceiver).

Changing the configuration in MII register 0 usually results in the
transceiver dropping the link beat, which will reset the link negotiation
and sensing.

This is different than setting the reset bit in MII register 0.  The reset
bit resets the internal state machines, in addition to dropping link beat
and restarting the autonegotiation and sensing.

> > The transceiver has a power-up default that the driver should not change.
> > The default is usually "autonegotiate".
> 
> How about putting in some code to warn if an autonegotiation capable card
> has the default set to something else? Anyway, this was not true in this
> case, as both the start-up messages and mii-diag showed autonegotiation
> capabilities.

I'm describing the general case.  Most MII transceivers have "strapping pins"
that allow them to be set to a fixed speed, or limit the advertised media
types.  This feature is primarily for use in hubs, where there is no
software that configures the MII management registers.  But some non-3Com
boards use this hardware feature to pre-configure the transceiver.

3Com boards come up from a hardware reset in fully-capable mode.

There is already a message that describes what media type is set in the
EEPROM.  If this setting isn't valid with the transceivers on the board, the
chip defaults to forced 10baseT mode.

> > The driver should not usually reset the transceiver.  It certainly shouldn't
> > do a reset each time the interface is activated, since it may take 3 seconds
> > before the negotiation completes or fails.
> 
> I don't quite understand this; how often is the interface activated so
> that you care for the 3 seconds?

Not everyone is using the machines in workstation mode -- don't assume that
your use pattern is typical.  There are several reasons for a down-up
cycle.  Not all of them are good reasons, but the driver shouldn't prevent
that type of use.

Also consider that transmits will fail for up to 3 seconds after starting
the interface.  Besides the chaos this causes for the driver transmit code,
those first transmits are probably ARPs to your nameserver and file server.
By the time the transmitter is ready, ARP has fallen back to slow-poll mode.

> > In default autonegotiation/autosense mode an MII transceiver should "just
> > work", without the driver have to set any configuration.
> 
> Agreed, but what is to be done in case it doesn't "just work"?

This case sounds like broken hardware on the remote end.  We shouldn't break
valid use just to work with broken hardware.

> > If the driver needs to force the link speed (and turn off autonegotiation),
> > it should write register 0.  If the driver knows it has been forced to full
> > duplex, it should set the FDX bit in reg 0 since that may be controlling
> > an LED.
> 
> But the current driver does not do this! I couldn't find any mdio_write to
> register 0 and anyway there is no possibility to force the link speed to
> 10base-T by using the module options. Should this be added to the driver?

I was speaking in general terms.  3Com runs the FDX LED directly from the
chip, not from the transceiver, and we have autonegotiation available on all
modern boards.  The module options are only needed for older (e.g. 3c595)
boards.

I've avoided adding forced media types for 3c905/B/C boards as module
options because of my tulip experience.  Too many people set a type that
forced full duplex, and then complain when performance is bad.  Or they set
100baseTx-SYM when the board has a MII transceiver.

We are lucky with the 3Com boards: we know exactly what transceiver types
exist and how they are connected.  With the 21140 chip the driver sometimes
had to guess and probe what type of transceivers might exist.  We needed an
override to allow the driver to work with boards where the guess was wrong.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Annapolis MD 21403