* Re: [9fans] tsleep / timer questions
@ 2005-03-28 1:28 YAMANASHI Takeshi
2005-03-28 3:38 ` Russ Cox
0 siblings, 1 reply; 12+ messages in thread
From: YAMANASHI Takeshi @ 2005-03-28 1:28 UTC (permalink / raw)
To: 9fans
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).
--
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-28 1:28 [9fans] tsleep / timer questions YAMANASHI Takeshi @ 2005-03-28 3:38 ` Russ Cox 0 siblings, 0 replies; 12+ messages in thread From: Russ Cox @ 2005-03-28 3:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Fwd: [9fans] Ad link
@ 2005-03-24 15:08 Brantley Coile
2005-03-24 15:54 ` Ronald G. Minnich
0 siblings, 1 reply; 12+ messages in thread
From: Brantley Coile @ 2005-03-24 15:08 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Actually I meant to say, 9fans only price.
I'll also give really good prices for the shelf with
10 blades as well. We sell these for $2,495 but I'll sell one to
9fans folk at the `we don't make any money' price of $1,500.
Begin forwarded message:
> We have a small eval board, a bare printed circuit board, that
> a single blade can plug into that allows people to play with
> a single drive. We list that for $285 including the blade.
> I'll get you one for $150. (A dharani only price)
>
> Brantley
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: [9fans] Ad link 2005-03-24 15:08 Fwd: [9fans] Ad link Brantley Coile @ 2005-03-24 15:54 ` Ronald G. Minnich 2005-03-24 21:15 ` Sam 0 siblings, 1 reply; 12+ messages in thread From: Ronald G. Minnich @ 2005-03-24 15:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 24 Mar 2005, Brantley Coile wrote: > Actually I meant to say, 9fans only price. I'll also give really good > prices for the shelf with 10 blades as well. We sell these for $2,495 > but I'll sell one to 9fans folk at the `we don't make any money' price > of $1,500. These are just raw disks, or is there a file system on there that does snapshots? ron ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Fwd: [9fans] Ad link 2005-03-24 15:54 ` Ronald G. Minnich @ 2005-03-24 21:15 ` Sam 2005-03-25 18:36 ` [9fans] tsleep / timer questions Devon H. O'Dell 0 siblings, 1 reply; 12+ messages in thread From: Sam @ 2005-03-24 21:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 24 Mar 2005, Ronald G. Minnich wrote: > >> Actually I meant to say, 9fans only price. I'll also give really good >> prices for the shelf with 10 blades as well. We sell these for $2,495 >> but I'll sell one to 9fans folk at the `we don't make any money' price >> of $1,500. > > These are just raw disks, or is there a file system on there that does > snapshots? <theskinny> AoE is a really light protocol for wrapping ATA commands in Ethernet frames. The EtherDrive blade is a nanoserver that sits on the network serving AoE and issuing ATA commands to its attached disk. The shelf provides a way for each blade to get its power and physical ethernet port. So you plug each EtherDrive into a switch, yourself into the (same) switch, and you access the disks -- whether it's ten or ten thousand. </theskinny> As an aside, since AoE is just a wrapper for the ATA commands, you can take a disk out of a machine, put it on an ED blade, and remount it over the network. So to answer your question, from the client side a full shelf looks like ten disks. We're currently developing raid / volume management software for plan 9 for our raidblade product. It should be released within the month. Sam ^ permalink raw reply [flat|nested] 12+ messages in thread
* [9fans] tsleep / timer questions 2005-03-24 21:15 ` Sam @ 2005-03-25 18:36 ` Devon H. O'Dell 2005-03-25 18:55 ` jmk ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Devon H. O'Dell @ 2005-03-25 18:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 18:36 ` [9fans] tsleep / timer questions Devon H. O'Dell @ 2005-03-25 18:55 ` jmk 2005-03-25 20:19 ` Devon H. O'Dell 2005-03-25 18:57 ` Russ Cox 2005-03-26 0:22 ` vdharani 2 siblings, 1 reply; 12+ messages in thread From: jmk @ 2005-03-25 18:55 UTC (permalink / raw) To: 9fans >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'. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 18:55 ` jmk @ 2005-03-25 20:19 ` Devon H. O'Dell 0 siblings, 0 replies; 12+ messages in thread From: Devon H. O'Dell @ 2005-03-25 20:19 UTC (permalink / raw) To: 9fans [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 18:36 ` [9fans] tsleep / timer questions Devon H. O'Dell 2005-03-25 18:55 ` jmk @ 2005-03-25 18:57 ` Russ Cox 2005-03-25 20:04 ` Devon H. O'Dell 2005-03-26 0:22 ` vdharani 2 siblings, 1 reply; 12+ messages in thread From: Russ Cox @ 2005-03-25 18:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 18:57 ` Russ Cox @ 2005-03-25 20:04 ` Devon H. O'Dell 2005-03-25 20:12 ` Russ Cox 0 siblings, 1 reply; 12+ messages in thread From: Devon H. O'Dell @ 2005-03-25 20:04 UTC (permalink / raw) To: Russ Cox, Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 20:04 ` Devon H. O'Dell @ 2005-03-25 20:12 ` Russ Cox 2005-03-25 20:23 ` Devon H. O'Dell 0 siblings, 1 reply; 12+ messages in thread From: Russ Cox @ 2005-03-25 20:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 20:12 ` Russ Cox @ 2005-03-25 20:23 ` Devon H. O'Dell 2005-03-25 21:36 ` Russ Cox 0 siblings, 1 reply; 12+ messages in thread From: Devon H. O'Dell @ 2005-03-25 20:23 UTC (permalink / raw) To: 9fans [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 20:23 ` Devon H. O'Dell @ 2005-03-25 21:36 ` Russ Cox 2005-03-26 8:30 ` Devon H. O'Dell 0 siblings, 1 reply; 12+ messages in thread From: Russ Cox @ 2005-03-25 21:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 21:36 ` Russ Cox @ 2005-03-26 8:30 ` Devon H. O'Dell 0 siblings, 0 replies; 12+ messages in thread From: Devon H. O'Dell @ 2005-03-26 8:30 UTC (permalink / raw) To: 9fans [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [9fans] tsleep / timer questions 2005-03-25 18:36 ` [9fans] tsleep / timer questions Devon H. O'Dell 2005-03-25 18:55 ` jmk 2005-03-25 18:57 ` Russ Cox @ 2005-03-26 0:22 ` vdharani 2 siblings, 0 replies; 12+ messages in thread From: vdharani @ 2005-03-26 0:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-03-28 3:38 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-03-28 1:28 [9fans] tsleep / timer questions YAMANASHI Takeshi 2005-03-28 3:38 ` Russ Cox -- strict thread matches above, loose matches on Subject: below -- 2005-03-24 15:08 Fwd: [9fans] Ad link Brantley Coile 2005-03-24 15:54 ` Ronald G. Minnich 2005-03-24 21:15 ` Sam 2005-03-25 18:36 ` [9fans] tsleep / timer questions Devon H. O'Dell 2005-03-25 18:55 ` jmk 2005-03-25 20:19 ` Devon H. O'Dell 2005-03-25 18:57 ` Russ Cox 2005-03-25 20:04 ` Devon H. O'Dell 2005-03-25 20:12 ` Russ Cox 2005-03-25 20:23 ` Devon H. O'Dell 2005-03-25 21:36 ` Russ Cox 2005-03-26 8:30 ` Devon H. O'Dell 2005-03-26 0:22 ` vdharani
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).