Chris,

You wrote...
 > yup, that's twice as much as me...  i'd bump up NKMEMCLUSTERS; right
 > now it's (1MB / CLBYTES), where CLBYTES is 8k, which yields 1MB in the
 > kernel malloc area...  you can probably double it safely; do so as a
 > kernel option, or by hacking alpha/include/vmparam.h.

I'll probably do something close to that.

 > Since you seem to be having trouble building kernels, you might want
 > to yank 64M of your RAM until you get one rebuild.  it might save you
 > some pain.

Actually, I haven't had time to try building a kernel.  I was just
estimating the time that the system would stay up before crashing and
guessing that I wouldn't be able to build a kernel in that time.  I'll
try removing the memory if I do have problems.

 > heh.  yeah, umm, there's an ill-conceived reset of the serial chip in
 > sccparam(); if you remove that, it behaves a _LOT_ better (i.e. it's
 > actually _usable_ on console...  8-)  for an example of what i mean,
 > take a look in
 > ftp.netbsd.org:pub/NetBSD/NetBSD-current/src/sys/arch/alpha/tc/scc.c,
 > i think is the path...

Yeah, I could see that as being bad.  Oops.  Will do.  Thanks.

 > Your mail sort of points out a slight (heh) coordination problem
 > that's going to grow, as time goes on: unless i keep putting out
 > (large!) source snapshots, or unless some reasonable way is found for
 > people using the alpha port to synch up with the NetBSD-current
 > sources, it's going to be relatively difficult to keep people
 > up-to-date with the latest changes.
...
 > Perhaps i ought to think about it after i've slept some...  8-)

Funny, I was just wondering and thinking about how source changes were
going to be distributed.  I had assumed you guys had already worked out
something with NetBSD; I hadn't looked into it, though.  I assume you've
looked at such things as sup, etc.

			-jeff

Jeff Kellem
Internet: composer@Beyond.Dreams.ORG
      or  composer@crl.dec.com