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

[Bogdan Costescu]

On Fri, 23 Jun 2000, Donald Becker wrote:

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

Delaying for 3 seconds doesn't mean "preventing that type of use". Can you
give an example where a 3 seconds delay is critical?

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

No, the packets will still be queued and transmitted later. Or you can
(AFAIK) delay returning from vortex_open until the interface is really
ready to work.

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

Agreed, but we should be more user-friendly in this case: either we say
"Your connection doesn't work. Can't sense the remote end!" or we advise
to use mii-diag.
Another (expensive) solution would be to try to set all modes on the MII
and see which one is working (by trying to read the MII remote end
registers); of course, we'd do this only if the (current) automatic
procedure didn't work, so we just add a test for it and the new code.

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

If the driver would guess the correct speed from the beginning, nobody
will force it. They start to fiddle with the options only when it's not
working...
And the statement about 3Com known-transceivers boards should only be a
positive point in this direction. If we know them, we should be able to
drive them correctly!

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De