Re: [9fans] tsleep / timer questions

Re: [9fans] tsleep / timer questions

[YAMANASHI Takeshi]

It's off topic from the subject...

> x40=; 9fs sources

I've got why you have "x40=;" as the prompt and
this should go into the tips.

I changed my prompt to "hostname@uname% " for fun
and "send" complained about that (reasonably).
--

Re: [9fans] tsleep / timer questions

[Russ Cox]

> > x40=; 9fs sources
>
> I've got why you have "x40=;" as the prompt and
> this should go into the tips.

actually it doesn't work in rc.
i use it with sh.  x40=(); would work
but that's a funny looking prompt.

russ

Re: [9fans] tsleep / timer questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Fri, Mar 25, 2005 at 04:36:18PM -0500, Russ Cox wrote:
> > Another (final, less important) question: what is the general
> > resolution of tsleep versus addclock0link going to be? 
> 
> Ultimately tsleep and addclock0link events are both
> triggered by the clock interrupt handler, so the precision
> is the same.  Tsleep inside a kproc is heavier weight,
> but if you need lots of context then the kproc can help
> out.  It sounds like in your case addclock0link is the way
> to go.  Whichever makes your code simpler.
> 
> Russ

Yes, it does. Thanks!

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] tsleep / timer questions

[vdharani]

> Related to my work writing a driver for the Ziatech ZT5503 SBC
> watchdogs, I've come up with a question.
>
> Obviously the watchdog needs to be `strobed' at some interval to
> keep it from resetting the machine (after it has been enabled).
> I'm having troubles figuring out how to do this.
>
> Taking a look at the driver for the Ziatech 5512 watchdog that
> Eric Van Hensbergen write for Inferno, I see that he's making
> use of addclock0link(), which makes sense. This seems to be
> overkill for my needs though. I'm not sure the resolution of the
> timer on the ZT5512 blades, but mine have a minimum resolution
> of 250ms, which means that they'd be strobed twice in their
> timeout period.
>
> That's not so bad, but some of the other resolutions (the timer
> supports 250ms, 500ms, 1s, 8s, 32s, 64s, 128s and 256s
> intervals), this can get to be an issue. I personally have no
> use for the 256s resolution, and I'm sure I'm the only person on
> the planet running Plan 9 on these blades, but I'd really like
> to have a driver that's not overkill.
>
> So, I thought a nifty solution would be to make use of the
> rendezvous stuff and call tsleep. But I don't understand how
> this should work. When the watchdog is enabled, I need to start
> some procedure that never returns. This would be easy in
> userland, where I could simply start another thread, but how do
> I do this in-kernel. If I've read in /dev/watchdog
>
> enable resolution 500ms
>
> and I've parsed that, how do I then call the procedure to do the
> timer?
>
> My procedure looked like (until I realized that it'd
> never work if I understand the behavior correctly, which I'm
> fairly certain I do):
>
> void
> watchdog_strobe(void)
> {
> 	for(;;) {
> 		if (!enabled)
> 			break;
>
> 		tsleep(wd_timer, return0, nil, wd_resolution);
> 		inb(IOP_Watchdog); /* Reading the IO port strobes the WD */
> 	}
> }
>
> So I'm stuck with the problem: how do I enable a separate timer?
>
> Hope the question is clear.

first, i hope i understood your question corectly. second, i use inferno
mostly but i guess this will do the trick in plan9 as well. i dont have
access to plan9 system next to me to check this.

kproc() starts a new kernel process starting from the function you pass.
so, you will call kproc with watchdog_strobe as the argument. kproc()
starts the process and returns immediately. you need to modify
watchdog_strobe function as needed by kproc().

hope this helps.

thanks
dharani

Re: [9fans] tsleep / timer questions

[Russ Cox]

> Another (final, less important) question: what is the general
> resolution of tsleep versus addclock0link going to be?

Ultimately tsleep and addclock0link events are both
triggered by the clock interrupt handler, so the precision
is the same.  Tsleep inside a kproc is heavier weight,
but if you need lots of context then the kproc can help
out.  It sounds like in your case addclock0link is the way
to go.  Whichever makes your code simpler.

Russ

Re: [9fans] tsleep / timer questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Fri, Mar 25, 2005 at 03:12:35PM -0500, Russ Cox wrote:
> It's in the portfns on sources:
> 
> x40=; 9fs sources
> x40=; 9p read sources/plan9/sys/src/9/port/portfns.h | grep addclock0
> Timer*		addclock0link(void (*)(void), int);
> x40=; 
> 
> and it's been that way as far back as the sources dump
> goes (2002).
> 
> Note that this is only a (relatively) recent addition to
> Plan 9; in Inferno there was no extra parameter.
> 
> Russ

Gah, I'm using the VMWare image at the moment -- it must be
terribly old. Thanks for pointing this out, and sorry I didn't
check this first.

Another (final, less important) question: what is the general
resolution of tsleep versus addclock0link going to be? Precision
isn't 100% important; the watchdog operates on a crystal that
guarantees that it will not fire before the timer runs out (and
averages about 30ms latency), but between the choice of running
this with addclock0link using the extra parameter and using a
kproc with tsleep, which would be recommended?

Thanks a lot!

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] tsleep / timer questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Fri, Mar 25, 2005 at 01:55:40PM -0500, jmk@plan9.bell-labs.com wrote:
> 	>So, I thought a nifty solution would be to make use of the
> 	>rendezvous stuff and call tsleep. But I don't understand how
> 	>this should work. When the watchdog is enabled, I need to start
> 	>some procedure that never returns. This would be easy in
> 	>userland, where I could simply start another thread, but how do
> 	>I do this in-kernel. 
> 
> that would be a kproc. look at some of the ether drivers, e.g. ether82557,c
> which actually has a kproc called 'watchdog'.

Aha! This does appear to be what I'm wanting to do. I saw the
watchdog procedure in ether82557.c, but wasn't able to really
figure it out. Searching for kproc makes more sense now :)

Thanks for this tip. I'll finish this driver up tomorrow.

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] tsleep / timer questions

[Russ Cox]

It's in the portfns on sources:

x40=; 9fs sources
x40=; 9p read sources/plan9/sys/src/9/port/portfns.h | grep addclock0
Timer*		addclock0link(void (*)(void), int);
x40=;

and it's been that way as far back as the sources dump
goes (2002).

Note that this is only a (relatively) recent addition to
Plan 9; in Inferno there was no extra parameter.

Russ

Re: [9fans] tsleep / timer questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Fri, Mar 25, 2005 at 01:57:41PM -0500, Russ Cox wrote:
> > Eric Van Hensbergen write for Inferno, I see that he's making
> > use of addclock0link(), which makes sense. This seems to be
> > overkill for my needs though. I'm not sure the resolution of the
> > timer on the ZT5512 blades, but mine have a minimum resolution
> > of 250ms, which means that they'd be strobed twice in their
> > timeout period.
> 
> the plan 9 addclock0link has an extra argument
> that lets you specify how many milliseconds should go by
> between calls to the function you register.
> 
> russ

Oh -- I didn't see this -- the only one I found was defined in
portfns.h as:

void	addclock0link(void (*)(void));

I must be missing something -- I don't see code for that in the
kernel either. If I'm missing something, I guess this would be
ideal rather than a kproc.

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] tsleep / timer questions

[Russ Cox]

> Eric Van Hensbergen write for Inferno, I see that he's making
> use of addclock0link(), which makes sense. This seems to be
> overkill for my needs though. I'm not sure the resolution of the
> timer on the ZT5512 blades, but mine have a minimum resolution
> of 250ms, which means that they'd be strobed twice in their
> timeout period.

the plan 9 addclock0link has an extra argument
that lets you specify how many milliseconds should go by
between calls to the function you register.

russ

Re: [9fans] tsleep / timer questions

[jmk]

	>So, I thought a nifty solution would be to make use of the
	>rendezvous stuff and call tsleep. But I don't understand how
	>this should work. When the watchdog is enabled, I need to start
	>some procedure that never returns. This would be easy in
	>userland, where I could simply start another thread, but how do
	>I do this in-kernel.

that would be a kproc. look at some of the ether drivers, e.g. ether82557,c
which actually has a kproc called 'watchdog'.

[9fans] tsleep / timer questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Related to my work writing a driver for the Ziatech ZT5503 SBC
watchdogs, I've come up with a question.

Obviously the watchdog needs to be `strobed' at some interval to
keep it from resetting the machine (after it has been enabled).
I'm having troubles figuring out how to do this.

Taking a look at the driver for the Ziatech 5512 watchdog that
Eric Van Hensbergen write for Inferno, I see that he's making
use of addclock0link(), which makes sense. This seems to be
overkill for my needs though. I'm not sure the resolution of the
timer on the ZT5512 blades, but mine have a minimum resolution
of 250ms, which means that they'd be strobed twice in their
timeout period.

That's not so bad, but some of the other resolutions (the timer
supports 250ms, 500ms, 1s, 8s, 32s, 64s, 128s and 256s
intervals), this can get to be an issue. I personally have no
use for the 256s resolution, and I'm sure I'm the only person on
the planet running Plan 9 on these blades, but I'd really like
to have a driver that's not overkill.

So, I thought a nifty solution would be to make use of the
rendezvous stuff and call tsleep. But I don't understand how
this should work. When the watchdog is enabled, I need to start
some procedure that never returns. This would be easy in
userland, where I could simply start another thread, but how do
I do this in-kernel. If I've read in /dev/watchdog

enable resolution 500ms

and I've parsed that, how do I then call the procedure to do the
timer? My procedure looked like (until I realized that it'd
never work if I understand the behavior correctly, which I'm
fairly certain I do):

void
watchdog_strobe(void)
{
	for(;;) {
		if (!enabled)
			break;

		tsleep(wd_timer, return0, nil, wd_resolution);
		inb(IOP_Watchdog); /* Reading the IO port strobes the WD */
	}
}

So I'm stuck with the problem: how do I enable a separate timer?

Hope the question is clear.

Thanks,

Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]