3c59x with linuxppc

[Andreas Tobler]

Bogdan Costescu wrote:
> 
> On Sat, 6 May 2000, Andreas Tobler wrote:
> 
> > In vortex_timer I had the blocker. At the end of the function I put the
> > following snippet in an if clause as it was before the patch. Doing so,
> > the machine doesn't hang anymore.
> >
> > if (next_tick) {                                      <---- added by me
> >       vp->timer.expires = RUN_AT(next_tick);
> >       add_timer(&vp->timer);
> > }                                                     <---- added by me
> 
> I don't quite understand how you got into this situation, because my
> source has these lines in it... I downloaded the whole driver (not the
> patch) - so there might be the difference. Please note that 0.99H that
> comes with kernels up to 2.2.15 is different from "clean" 0.99H that you
> get from Mr. Becker's site (timer handling included).

Sorry the dumb Q, where did you download the driver from? I had a look
at several driver sources, Don B's site, Andrews's site, no I don't see
these lines included in the driver.

> On the other hand, I don't know why it gets there. next_tick is
> initialized ( 0 ) in the first lines of vortex_timer, but it should be set
> by the media handling according to the media table. Can you run the driver
> with vortex_debug > 2 and send the logs produced by vortex_timer?

I reread the code several times  an from my sight the next_tick is never
changed from 0.
The places where it is changed is the switch statement in vortex_timer
in 
case XCVT_MII: case XCVR_NWAY, here it is set to 60*HZ.
The next place is in 'if (!ok)' when the media selection fails.
next_tick = media_tbl[dev->if_port].wait.
Those two places where not covered with my two cards. (3c590/3c905b)

So the next_tick is zero. And I don't know exactly what the behaviour of
RUN_AT(0) is. I can only assume that it blocks. 

> (One should appear very soon after the driver initialization and others
> every 1 minute - if things are working as they should...)
> A working vortex_timer (i.e. one that sets this variable correctly) is
> important for media change handling; what you have done with these lines
> is avoiding updating with wrong data - but we need to find out how that
> wrong data was produced. In your case, I would say that the timer is not
> updated, meaning that vortex_timer will not be run a second time.

This is what I see, or mean to see. Right now I can't test.
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) {
	  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;

Or is this completely wrong?

Regards

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