[vortex-bug] 3Com 920 ST03

[Donald Becker]

On Fri, 20 Jul 2001, Bogdan Costescu wrote:

> > 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):

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

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

Entirely cosmetic.  I almost removed this section, since it only
mattered for the original 3c590 series.  The 3c900 and later series are
real bus masters and don't require large buffers.

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

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

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

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.

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

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

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

We only care about the very unlikely case where the whole Tx queue was
just emptied.  If the queue was full and is now only slightly less than
full, we still don't want to queue a new packet.

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

Or, presumably, recognized that the 'C' version changed the behavior.
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.

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

Yup, I used to plug a laptop into a Cisco switch and this bogus
"feature" was very frustrating.  Having it occur on a desktop machine is
even worse.

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

The other drivers shouldn't be resetting on open(), unless a quirk of
the hardware requires it.

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

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

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

Yup, it's the right work-around.  This is clearly a bug in
the transceiver implementation. 

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993