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

[Donald Becker]

On Sun, 25 Jun 2000, Bogdan Costescu wrote:

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

There are several tools that do the equivalent of
  ifconfig down; muck with a parameter; ifconfig up
They expect that the interface will drop few, if any, packets.

> 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 is a bad idea.

> 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'm not certain what you mean by this.  Not all transceivers support the
"remote page" facility.

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

You misunderstand: it's sometimes impossible to autoselect the correct
transceiver type on the Tulip.

In general it's also impossible to always guess the link speed without
autonegotiation.  If you unilaterally generate 100baseTx link beat, you may
clog a 10baseT repeater with a continuous collision.  If you generate only
10baseT link beat, your link may lock on 10baseT even if both ends can do
100baseTx.

Anyway, that's unrelated.  The transceiver in question falls back to
autosense if autonegotiation fails.  This procedure is known to work.  I
know if no current production MII transceivers that problems in this area.

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

The problem that's the source of this discussion is almost certainly a buggy
repeater.  This is *not* a common occurence, and the driver should not break
normal operation to support uncommon buggy hardware.

It's fine to support common broken hardware, or trival work-arounds that
does not impact the operation of correct hardware.  But putting random hacks
like this in a driver isn't a good idea.

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