[9fans] OK, cpu server is up.

[9fans] OK, cpu server is up.

[ron minnich]

That last change for devrtc did the trick.

the little 'no moving parts CPU server' comes up and is ready just fine.

whew.

I have some fixes for the IRQ stuff for cyrix and a few other things ...
who vets this stuff for inclusion into the kernel or 9load tree? I hope
somebody nicer than Linus :-)

ron

Re: [9fans] OK, cpu server is up.

[okamoto]

> the little 'no moving parts CPU server' comes up and is ready just fine.

Are you using a file sever of v9fs on Linux, and Plan 9 CPU server,
and Plan 9 terminals system?   And you can use grid computing using
your Plan 9 CPU server?

Kenji

Re: [9fans] OK, cpu server is up.

[andrey mirtchovski]

you can get grid computing by virtue of plan9's private namespace only :)

i suggest taking a look at globus -- that's the best tool to teach someone
that plan9 is a better way to look at the world.

andrey

On Fri, 25 Apr 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> > the little 'no moving parts CPU server' comes up and is ready just fine.
>
> Are you using a file sever of v9fs on Linux, and Plan 9 CPU server,
> and Plan 9 terminals system?   And you can use grid computing using
> your Plan 9 CPU server?
>
> Kenji
>

Re: [9fans] OK, cpu server is up.

[ron minnich]

On Thu, 24 Apr 2003, andrey mirtchovski wrote:

> you can get grid computing by virtue of plan9's private namespace only :)

yes, I forgot to answer the grid computing part of that question.

These little CPU servers are ideal for grid computing. One major
improvement is that it is impossible for them to run Globus.

ron

Re: [9fans] OK, cpu server is up.

[ron minnich]

On Fri, 25 Apr 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> Are you using a file sever of v9fs on Linux, and Plan 9 CPU server,
> and Plan 9 terminals system?   And you can use grid computing using
> your Plan 9 CPU server?

no, this setup is a kludge just to get me there. Proof of concept, and
next comes the transition to all Plan9-based hardware. Also, I am trying
to keep it to two physical pieces: the clump of geodes and a laptop, as I
plan to bring this to Usenix if anybody wants to see it (I hope there is a
Plan9 BOF ...)

The auth and terminal are on my IBM Thinkpad X24, and are the same vmware
image running under linux (i.e. my terminal is the auth/kfs server). The
CPU server is a Geode (Geode rhymes with: slow) board (Advantech PCM-5823)
running LinuxBIOS out of FLASH rom with 9load loaded onto a compact flash.

LinuxBIOS loads 9load from the compact flash. This has proven to be very
handy for debugging, as I can pop the CF out of the geode and put it in my
X24 if I need to fix 9load for anything.

The plan9 host is using host-only networking on vmnet1. The Geodes are on
eth0 (ether0 in Plan9 parlance). 9load DHCP requests don't make it across
the eth0->vmnet1 gap, so I have to run linux dhcpd.

Two other things I have to do: enable ipforwarding on the linux side so
that the geode packets get to the vmware image; and hard-wire the Linux
ARP tables for the Geode (more on that later).

9load comes up on the geode and sends dhcp requests. Linux responds with a
host name and IP address. 9load then loads the 9pccpu kernel from Linux,
and connects to the auth server running in vmware.

Here is an interesting problem. 9load gets its IP address but won't
respond to ARP requests, so the tftp load of 9pccpu can't happen as Linux
doesn't have an ARP entry for the geode. I assume on plan9 this is not an
issue, but I have to hardwire the ARP cache for the CPU server or nobody
can talk to it.

Also, there is no plan9.ini for the 9load to read, and for some reason I
still can't get environment variables from 9load to 9pccpu, so I have also
had to hard-wire environment variables in the 9pccpu kernel. So the 9pccpu
that 9load downloads from Linux has one or two mods to it :-)

Once the 9pccpu is loaded, it contacts the auth server in vmware, and from
there things are pretty straightforward, and up it comes.

There are mods to both 9load and 9pccpu.

9load cyrix interrupt routing code is completely busted (no shock there,
it's almost impossible to test this stuff unless you're using linuxbios)
and I have made some quick fixes to it to get it working. I just run the
many Geode devices (all 2 of them) at IRQ 9. There are a few other things
9load does that have proven to be dangerous in a non-bios environment and
I am trying to put together a patch set for possible acceptance by the
Plan 9 kernel folks.

The kernel itself doesn't have a huge number of changes, although again
there are IRQ routing issues and a few other things.

So, short story is, it all works, it's held together with gum and wire
right now, and the effort for the next month is to get it working more
smoothly and slowly rip out as many of my changes as I can. I may just put
9pccpu into the CF and dispense with 9load altogether, since 9load takes a
long time to get going and boot something.  But we'll see -- 9load is very
handy in many ways.

I plan to update the wiki with all this info next week.

ron

Re: [9fans] OK, cpu server is up.

[Charles Forsyth]

>>Here is an interesting problem. 9load gets its IP address but won't
>>respond to ARP requests, so the tftp load of 9pccpu can't happen as Linux
>>doesn't have an ARP entry for the geode. I assume on plan9 this is not an
>>issue, but I have to hardwire the ARP cache for the CPU server or nobody
>>can talk to it.

by curious coincidence i happened earlier today to notice that
dhcpd(8) observes:
         These programs support booting over the Internet.  They
          should all be run on the same server to allow other systems
          to be booted.  Dhcpd and tftpd are used to boot everything;

`all on the same server'?  i wondered about that at the time,
but now i think i see:
dhcpd makes an arp entry which is what probably allows
it to work: tftpd ends up using that entry and 9load is never asked.
if dhcpd and tftpd are on different machines, it won't work
(unless i suppose proxyarp is also set)

Re: [9fans] OK, cpu server is up.

[ron minnich]

On Fri, 25 Apr 2003, Charles Forsyth wrote:

> dhcpd makes an arp entry which is what probably allows
> it to work: tftpd ends up using that entry and 9load is never asked.

Did you verify that dhcpd makes that arp entry? I had made that
assumption.

It's an interesting way of ensuring that if someone talks to your dhcpd,
they can only talk to your machine from that point on. Is this an
intentional security thing, I wonder.

Or is it due to the fact that somebody once had a building of diskless Sun
nodes and one day had 50 or 100 of them home to the wrong bootp server
(happened to me once ...)

ron

Re: [9fans] OK, cpu server is up.

[David Presotto]

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

yes, dhcpd makes the entry.

Its not intentional security thing just 9load being minimal.  However,
over the years, 9load has become so friggin big that I might as well
put ARP into it too, it'ld hardly be noticable.

Dhcpd loading the arp cache is just there because it has to be.
Otherwise the responses might not work.  That's because if the
broadcast flag isn't set in the client requests, replies are
unicast.  If the reply is unicast, the server has to ARP to get
the clients ether address.  Since the client hasn't gotten its
address yet, it can't answer the ARP...

Of course, once 9load gets an address, it should be ready to
answer ARPs.  That way we could separate the dhcp server and
tftp server.  On my infinite list.

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] OK, cpu server is up.
Date: Fri, 25 Apr 2003 08:38:14 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0304250836140.8939-100000@maxroach.lanl.gov>

On Fri, 25 Apr 2003, Charles Forsyth wrote:

> dhcpd makes an arp entry which is what probably allows
> it to work: tftpd ends up using that entry and 9load is never asked.

Did you verify that dhcpd makes that arp entry? I had made that
assumption.

It's an interesting way of ensuring that if someone talks to your dhcpd,
they can only talk to your machine from that point on. Is this an
intentional security thing, I wonder.

Or is it due to the fact that somebody once had a building of diskless Sun
nodes and one day had 50 or 100 of them home to the wrong bootp server
(happened to me once ...)

ron

Re: [9fans] OK, cpu server is up.

[C H Forsyth]

i did check that it can indeed make such an entry (eg, dhcpd.c:/^arpenter) and that
it called it in plausible places (eg):
		if(bp->htype == 1)
			arpenter(up->raddr, bp->chaddr);
i was fairly sure that the surrounding conditionals
had it called in response to a 9load packet because it
was only prevented if the request was
gatewayed by some intervening device,
or the bootp (sorry, dhcp) flags said `broadcast',
but 9load sets them to 0.