>  > that's interesting; i've seen that error exactly once, i think.
>  > how much RAM do you have?  (i'd bet that you've got more than I do,
>  > and the constants i picked are just too small...)
> 
> 128MB.

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.

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.

> Oh, and you weren't kidding about the serial driver.  Oh my; I'm going
> to have to fiddle with my console server to see if I can workaround it
> to login on the console when multiuser.

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


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.

You folks should mostly be able to just grep the .../arch/alpha
directory from the path above, and plop it into your tree, but that
still doesn't include _all_ the fixes i've made...

Perhaps i ought to think about it after i've slept some...  8-)



later,

chris