[vortex-bug] 3Com 920 ST03

[Bogdan Costescu]

> Rb was from almost a year ago, the interim versions have been
> Rc/Rd/Re/S/Sa.

Maybe, but I haven't seen them... 8-)

> Yes, and it avoids chip table entries that forget the HAS_NWAY flag.

Missed that. In this case, what is the meaning of HAS_NWAY, even more
is it still needed ?

> The semantics there are not well thought out.  The user will still want
> to see the transceiver status, even if it's not the transceiver in use.

Can you explain more, please ? If I have the coaxial cable connected to
the BNC connector, what additional info does reading the MII transceiver
status bring ?

> That's a valid issue: we must add a module option to explicitly force
> the transceiver speed/duplex, or to turn on autonegotiation.

When I wrote my previous reply, I was thinking that there should be an option
to select transceiver reset, like between the "old" and the "new" style.
But I now see that things are more complicated in the "new" style...

> Or, presumably, recognized that the 'C' version changed the behavior.

I'm not sure about this one. My impression was that the 'B' version did the
same, but I might be wrong. I only use these 2 versions of 3Com cards,
so I don't know how the previous ones worked.

> I didn't realize that we were bringing down the link.  I'm very opposed
> to resetting the transceiver in other drivers, and here we were doing it
> all the time.
> ...
> The other drivers shouldn't be resetting on open(), unless a quirk of
> the hardware requires it.

I though that bringing down the link is desired, for restarting
autonegotiation and getting into a stable state (if autonegotiation finishes).
IIRC, mii-diag reports on a forced link "this transceiver does not report
the sensed link speed", so resetting is a way to see what's going on. Or
maybe I don't correlate the two things correctly...

I also have tulip, eepro100 and rtl8193 -driven cards connected to the
same Cisco switch and they are all behaving the same way (need time
until the port is activated). I assumed that they all bring down the link in
order to restart autonegotiation; if you say that they shouldn't, then there
is another reason for this behaviour...

> Yes, we must bring the link down to restart autonegotiation.  But if the
> link was previously forced to a specific speed, we might not want to
> change it (assume that it was intentional).

I mostly agree. The link could have been forced by:
  1. a non-autonegotiating partner - nothing to do
  2. another operating system - presumably this should mean a reboot
      which should also bring the link down
  3. another Linux driver running before - this is very unlikely, but if the
     previous driver had problems with media settings... This would most
     likely happen when there are several drivers or versions around.
  4. this driver which was forced - maybe the user had tried to force
     the driver to operate at a speed higher than technically possible and
     tries a down/up sequence for restoring the link to a sane state.

I said "mostly" because of the uncertainties in cases 2-4 and because
I'm not sure that this is an exhaustive list. However, in most of the cases,
'mii-diag -R' or simply disconnecting then connecting again the cable
should produce the desired result - which means that documentation has to be
changed and users re-educated...

I said "in most of the cases" because my last Friday's tries with
non-resetting transceiver brought the Cisco port to a very strange state: it
would not autonegotiate even if I run 'mii-diag -R', disconnect/connect
cable, power off/on the workstation (to reset whatever card registers would
have been screwed up). mii-diag says "negotiation did not complete". I think
that the switch has some kind of protection which is triggered when too many
link parameters change in a too short time; I did play...


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