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

[Bogdan Costescu]

On Sun, 25 Jun 2000, Donald Becker wrote:

> If you reset the transceiver on 'down+up', you will drop up to three seconds
> worth of received packets.  This is Bad.

Another one of your statements! Can you give at least once a good
explanation ?
What I was proposing was to have the "up" part blocking until the card is
ready. What prevents this to take as much as needed ? The interface is not
marked "up" or "running" until you return from vortex_open (AFAIK), so the
transmission is not affected, as the network is simply not ready yet. You
loose some packets that were maybe on the net during this time; again, the
network is not ready yet! So what's the catch ?
And the old question again: how often is an interface brought "down+up"
and what are (or how frequent used) the applications that need to do this
themselves ? (I'm not talking here about rmmod/insmod, as this is
user-driven where 3 seconds may be less than typing/clicking speed of
some).
And... we are discussing here a method of getting a link when the current
methods are failing. So I think that 3 seconds delay is much better than
no-link. The user might do it using mii-diag anyway, which will take
the same amount of time and will not have the protection given by a
blocked vortex_open...

> The bit to read is either "autonegotiation complete" in register 5, or link
> beat in register 4.

Register 0 was only a suggestion that came specifically from this case. I
have seen link "indication" in several places in the MII registers and
didn't know which one is better/more reliable. We can have one or more of
them...

> Some MII transceivers report the link speed sensed in register 5 when
> autonegotiation did not complete, but this cannot be relied upon.
> Similarly, the negotiated duplex and speed may be reported in the register
> 0, but this is not standardized.

I not really interested in other (than 3Com) cards for the moment. Are you
saying that the 3Com cards have non-standardized registers ?

> If by "trying all of the modes" you mean setting the link speed explicitly,

Exactly!

> this isn't the correct approach:
>    It should never be necessary

The current problem somehow proved the contrary!

>    It aborts any autonegotiation or autosensing in progress.

Yes, that's why I was suggesting to do this at the end of whatever
media setting we are doing and do it only if other methods fail.

>    Forcing 100baseTx will clog some 10baseT repeaters, which will output
>      continuous collisions on all ports.  This can cascade and shutdown a
>      whole repeated network!

I don't argue, just that I was thinking of doing the other way around:
first try 10baseT which should work if remote is either 10 or 100. If the
link is set (which would have been the case here), we might as well stop
here, having 10baseT is better than nothing. If we feel adventurous, we
might try 100 but only for a short period of time, if it doesn't work we
get back to 10 and we are set (I'm not sure about this last sentence in
the light of what you said before, as I don't have experience with
repeaters).

> It may be acceptable for the driver to reset the autonegotiation/autosensing
> if no link beat is detected for three seconds after activating the
> interface, but we should only only do this if it is confirmed to fix a
> problem.

Finally! Although I don't agree with the part about restarting auto*. The
auto* didn't do anything useful in this case the first time (at card
init), do we have any hope that will do the second time?

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