3c59x with linuxppc

[Andreas Tobler]

Bogdan Costescu wrote:
> That's how I interpret it, too.

Fine, sitting around alone and trying to find out why something isn't
working can be frustrating:-)

> > But I think next_tick should be changed from zero in every case(card type).
> > Shouldn't we set the next_tick like 'next_tick =
> > media_tbl[dev->if_port].wait' in every case part of the switch in vortex_timer?
> > E.g.
> > switch (dev->if_port) {

What about when I put in here:
-------->   next_tick = media_tbl[dev->if_port].wait

> >         case XCVR_10baseT:  case XCVR_100baseTx:  case XCVR_100baseFx:
> >               if (media_status & Media_LnkBeat) {
> >                 ok = 1;
> > -------->   next_tick = media_tbl[dev->if_port].wait
> >                 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;
> >
> 
> You still miss the case when there is not link beat. IMHO, vortex_timer
> should be run periodically to be able to signal when the link is missing,
> but also to be able to recover when the link gets back; in your code, it
> is run when you have link, but as soon as the link is missing, it is not
> re-added and you will not see when the link comes back, so you'll have to
> rmmod/insmod to get the network working again.

I have to say these are only ideas in a dry state, means I can't test
them now.

And what about the approach from Don, in his N,L series he sets the
next_tick at init to 60*HZ?

Regards,

Andeas
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-request@beowulf.org