[vortex] 3c590 media selection

[Andrew Morton]

Donald Becker wrote:
> 
> On Sun, 7 Jan 2001, Andrew Morton wrote:
> 
> > I've been looking into a 590 problem report where if the
> > 10baseT cable is pulled out the NIC goes inoperative.
> >
> > What happens is that the selection logic rotates to
> > 10base2 and then gets stuck there because 10base2
> > has no link beat indication.
> 
> Yes, that's a problem.  It's a hardware limitation.
> 
> IIRC, we must select the 10baseT transceiver for some significant time to
> reliably detect 10baseT link beat, so we risk dropping a 10base2 packet if
> we poll.

1.4 seconds.

> ...
> 
> Yup, 10base2 is bad but AUI is worse.  You can't use heartbeat.
>
> ...
>
> > I don't really see a sensible algorithmic fix for this,
> > so I took the tx timeout logic out again.
> >
> > So we're left with forcing the media type via
> > module parameters.
> 
> That was my conclusion.
> 
> The alternative is logic that combines
>    If we have ever seen 10baseT link beat, poll 10baseT when we have no Rx
>    traffic for T seconds.
>    If we have ever received 10base2 packets, don't switch to AUI.
> 
> But this doesn't seem worthwhile, given that the 3c590 is ancient.

Fair enough.

> > But there's a problem with the vortex_timer logic.  Even
> > if we try to force 10baseT via `options=0', this code:
> >
> >     media_status = inw(ioaddr + Wn4_Media);
> >     switch (dev->if_port) {
> >       case XCVR_10baseT:  case XCVR_100baseTx:  case XCVR_100baseFx:
> >         if (media_status & Media_LnkBeat) {
> >           ok = 1;
> >           if (vortex_debug > 1)
> >             printk(KERN_DEBUG "%s: Media %s has link beat, %x.\n",
> >                    dev->name, media_tbl[dev->if_port].name, media_status);
> >         } else if (vortex_debug > 1)
> >           printk(KERN_DEBUG "%s: Media %s is has no link beat, %x.\n",
> >                    dev->name, media_tbl[dev->if_port].name, media_status);
> >         break;
> >
> > will always cause the driver to advance onto the next media type,
> > which causes it to get stuck on 10base2.
> 
> It shouldn't -- see the  ok=1  path.

In this case, dev->if_port is XCVR_10baseT, from `options'.  But there's
no link beat, so `ok' remains at zero and we go on to select the next
media type.

I tested 0.99Ra with the 3c590, BTW.  It too got stuck on the 10base2
port when the 10baseT cable was removed.

> > So what I did was to add a new flag to the device structure
> > `media_was_forced'.  Set it in the processing of module
> 
> I use the name  medialock  in my drivers.

I'll do that.

Thanks.