Fwd: [9fans] Ad link

Fwd: [9fans] Ad link

[Brantley Coile]

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

Re: Fwd: [9fans] Ad link

[Ronald G. Minnich]

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

Re: Fwd: [9fans] Ad link

[Sam]

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

Re: Fwd: [9fans] Ad link

[Ronald G. Minnich]

so should geoff port ken's file server to coraid :-)

ron

Re: Fwd: [9fans] Ad link

[Russ Cox]

> so should geoff port ken's file server to coraid :-)

first coraid has to add worm over ethernet.

russ

Re: [9fans] Ad link

[Brantley Coile]

What would that be like?
   Brantley

On Mar 24, 2005, at 5:47 PM, Russ Cox wrote:

>> so should geoff port ken's file server to coraid :-)
>
> first coraid has to add worm over ethernet.
>
> russ
>

Re: [9fans] Ad link

[geoff]

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

I think Russ was joking, but accessing a WORM jukebox via ATA would
presumably require ATAPI, to get access to the SCSI CCS or MMC command
set, whatever it's called (the one that controls jukeboxes).  I've
never heard of an ATA(PI) WORM jukebox and it wouldn't help with
existing SCSI WORM jukeboxes, such as mine.

In any event, SCSI, ATA and AoE should all be able to coexist in one
kernel.

[-- Attachment #2: Type: message/rfc822, Size: 2881 bytes --]

From: Brantley Coile <brantley@coraid.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>, Russ Cox <russcox@gmail.com>
Cc: 
Subject: Re: [9fans] Ad link
Date: Fri, 25 Mar 2005 10:34:20 -0500
Message-ID: <98ed931981d9d952e885f91395286183@coraid.com>

What would that be like?
   Brantley

On Mar 24, 2005, at 5:47 PM, Russ Cox wrote:

>> so should geoff port ken's file server to coraid :-)
>
> first coraid has to add worm over ethernet.
>
> russ
>

Re: [9fans] Ad link

[Russ Cox]

> I think Russ was joking, but accessing a WORM jukebox via ATA would

i was joking, but jmk points out that woe might
be an appropriate acronym nonetheless.

russ

Re: Fwd: [9fans] Ad link

[McLone]

On Thu, 24 Mar 2005 17:47:47 -0500, Russ Cox <russcox@gmail.com> wrote:
> first coraid has to add worm over ethernet.
i see woe here.
--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: Fwd: [9fans] Ad link

[geoff]

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

I started an sdaoe.c for the cpu kernel for the AoE v0 blades that
Coraid generously sent me, but haven't got it working correctly yet.
They have also sent some v1 (production) blades and my code for those
isn't quite finished, yet alone working yet.

Given that my current file server (including the snapshot just
released) has the sd machinery from the cpu kernel in it, which is how
I got the cpu kernel's IDE code into the file server kernel, putting
AoE into the file server, once it's working in the cpu kernel, should
be easy.  It could probably even be put into the bootstraps.

[-- Attachment #2: Type: message/rfc822, Size: 2872 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: Fwd: [9fans] Ad link
Date: Thu, 24 Mar 2005 15:31:39 -0700 (MST)
Message-ID: <Pine.LNX.4.58.0503241531240.18003@enigma.lanl.gov>

so should geoff port ken's file server to coraid :-)

ron

Re: Fwd: [9fans] Ad link

[vdharani]

> We're currently developing raid / volume management software
> for plan 9 for our raidblade product.  It should be released
> within the month.
thats very good to know!

thanks
dharani

[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 --]

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'.

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]

> 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

[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]

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: 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

[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: 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 --]

[9fans] Kernel interface manpages

[Devon H. O'Dell]

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

Ok, so spawning from my recent questions from the list, it
appears that we'd probably benefit from some concise, well
written man pages for kernel interfaces. I know Inferno has
(some of?) these, but as with addclock0link, ours does differ.

I'd be willing to write some extra man pages for kernel
interfaces. What'd be the best way to go about doing this?
Simply read through the {port}fns.h and write?

Should I do this?

--Devon

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

Re: [9fans] Kernel interface manpages

[Russ Cox]

that would be great.  starting with the inferno man pages
is probably a good idea, modulo licensing issues which i'm
sure can be worked out.

on the list of things worth documenting: qio, sleep/wakeup,
waserror, spl*, ilock/iunlock,
generic driver interfaces: ether, uart, sd, vga.

the vita pages cover some of these already.

russ


On Sat, 26 Mar 2005 09:36:29 +0100, Devon H. O'Dell
<dodell@offmyserver.com> wrote:
> Ok, so spawning from my recent questions from the list, it
> appears that we'd probably benefit from some concise, well
> written man pages for kernel interfaces. I know Inferno has
> (some of?) these, but as with addclock0link, ours does differ.
>
> I'd be willing to write some extra man pages for kernel
> interfaces. What'd be the best way to go about doing this?
> Simply read through the {port}fns.h and write?
>
> Should I do this?
>
> --Devon
>
>
>

Re: [9fans] Kernel interface manpages

[Devon H. O'Dell]

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

On Sat, Mar 26, 2005 at 12:45:40PM -0500, Russ Cox wrote:
> that would be great.  starting with the inferno man pages
> is probably a good idea, modulo licensing issues which i'm
> sure can be worked out.
> 
> on the list of things worth documenting: qio, sleep/wakeup,
> waserror, spl*, ilock/iunlock,
> generic driver interfaces: ether, uart, sd, vga.
> 
> the vita pages cover some of these already.
> 
> russ
> 

Charles contacted me off-list about this and said that he had
already done some initial work on this some years ago. I'll
try my hand at finishing it up :)

--Devon

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

Re: [9fans] Kernel interface manpages

[vdharani]

> Ok, so spawning from my recent questions from the list, it
> appears that we'd probably benefit from some concise, well
> written man pages for kernel interfaces. I know Inferno has
> (some of?) these, but as with addclock0link, ours does differ.
>
> I'd be willing to write some extra man pages for kernel
> interfaces. What'd be the best way to go about doing this?
> Simply read through the {port}fns.h and write?
>
given that most functions are similar to inferno, may be the ideal thing
to do is to simply copy the current inferno man pages and go from there.
not sure if license is an issue.

thanks
dharani

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: Fwd: [9fans] Ad link

[vdharani]

>> 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.
oh, thank you. thats affordable. can i get a couple of boards or limit 1?

> 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.
this is not in my range, but can you give a rain check? when i need and
can afford, sure i would buy one.

and again, this is limit 1?

thanks again,
dharani

Re: [9fans] Ad link

[Brantley Coile]

No limits within reason.  I'll have a hard time if someone orders
30 shelves!!  Jim will kill me! :)

You can have more than 1 eval at that price.

I just hate expensive eval boards!  We are working on a new
board with a Cirrus part and they want $2,500 for the eval
card, that is similar to the card that Ron is using  that costs $150.
I want to sell stuff in a way that I would want to buy it.

  Brantley

On Mar 25, 2005, at 3:51 AM, vdharani@infernopark.com wrote:

>>> 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.
> oh, thank you. thats affordable. can i get a couple of boards or limit
> 1?
>
>> 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.
> this is not in my range, but can you give a rain check? when i need and
> can afford, sure i would buy one.
>
> and again, this is limit 1?
>
> thanks again,
> dharani
>