[vortex-bug] 3Com 920 ST03

[Bogdan Costescu]

Hi Don,

I apologize for the late reply, but I've had a very busy week...

> I've implemented two additional fixes to this problem:

You've done more than that 8-) I'll take them one by one (based on a diff
between Rb and T):

- the code to print the card info was changed. I was hoping that changes
in this area would correct the situation for Cyclone/Tornado which don't
have 8K RAM split 3:5, but 2K RAM split 1:1 which can't be changed. Just
cosmetic, though...

- the condition for looking for MII transceivers was changed to also do it
whenever the card NWAY capabilities, even if this is not the selected
interface. This has the advantage that even if 'options' is 0 or 4, MII
ioctl's work; the disadvantage is that they also work even for 'options'
which don't have anything to do with MII, like 1, 3, 5 which is confusing;
I suggested in a previous message returning something like -EINVAL when a
MII ioctl is called on a non-MII media.
I might have missed it, but how do you still get non-MII media for cards
that have both MII and non-MII (NWAY + BNC/AUI - the Cyclone Combo f.e.) ?
Also, added to the non-resetting of the transceiver, it screws up media
settings when tried repeatedly insmod/ifconfig with different media
options (read below).

- there is some code added with the comment "Check for a just-cleared
queue." where cur_tx - dirty_tx is checked against TX_QUEUE_LEN - 2. Why
against TX_QUEUE_LEN - 2 and not TX_QUEUE_LEN ? You already have
TX_QUEUE_LEN != TX_RING_SIZE ...

>      Limit the RxReset and TotalReset so that it doesn't reset the
>        transceiver
> ...
> Take note of the first fix.  It keeps the 3c905C from resetting the
> transceiver with every open.  DHCP clients rapidly cycle the interface
> up and down, and the cycling link beat that can cause the first few
> packets to be dropped or permanently confuse some switches.

This is something that I wanted to do for some time, but never found the
right moment... My reason is that resetting the transceiver is bad for
cards connected to some Cisco switches that use STP and only activate the
port one minute (without 'fastport' option) after the link is established.
And my workstation is affected by this... Now I can use the network
sooner. 8-) Would it be possible to do this to other drivers as well ?

But I'm still worried about the possible implications. In some situations,
resetting the transceiver exactly once might be a better solution (not in
my case, though 8-)). But the worst situation that I could find is when
the transceiver is switched between different media settings. For example,
after using 'options=0', if I try to either use 'options=8' or no options,
which should autonegotiate, I still get the old 10-HD media settings,
because (AFAICS) the autonegotiation is not re-started - which was
previously done by the transceiver reset.
One solution might be to do this in vortex_timer(): check for
capabilities, current media and media state and reset transceiver if
something better could be expected. However, making this decision might
not be easy to do. And for those affected by the above-mentioned Cisco
problem, it would mean that the connection would suddenly be broken for
one minute...

>      Detect transceivers with
> 	if ((mii_status & 0xf800)  &&  mii_status != 0xffff) {

So you define a "good" transceiver as one that reports as supported
at least one of the normal speeds. Seems good to me and it's better than
the old check, anyway...

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