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

[Bogdan Costescu]

On Sun, 25 Jun 2000, Donald Becker wrote:

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

ifconfig does vortex_open AFAIK. If vortex_open blocks until interface is
read, I see no problem.

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

It's easy to throw a statement like this! Can you also give an
explanation?

> > 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 mean: we leave the current code in, but at the end of media-setting-for- 
MII code we check if it's working by trying to read the "link partner
ability" (if we have this register). If we read 0 or something stupid,
then we try one by one all the modes that are available on the
transceiver. That does not modify the way the driver currently works, it
just adds some code which is only executed if the current code doesn't do
it right.

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

I don't argue here... I was mostly talking about 3Com cards, not tulips.

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

Maybe it's better to lock on 10baseT than to not function at all...

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

As I wrote above, we only add a check and some code that is not executed
in normal situations.

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