Hi,

I had the same problems on my dual, but not on the quad
with less memory and slower CPUs.  Who knows.  Anyway my custom
kernel file looks like below.  The NKMEMPAGES at 8192 seems to 
be enough to run build.sh, some other misc stuff, and my background
cpu intensive jobs.

cheers

bruce

====================
# $NetBSD: GENERIC.MP,v 1.3 2004/04/20 15:55:30 pk Exp $
#
# Generic Sparc kernel configuration with multiprocessor support.

include	"arch/sparc/conf/GENERIC"

options 	MULTIPROCESSOR		# include multiprocessor support
options		KMEMSTATS		# kmem stats
options		NKMEMPAGES=8192		# kmem pages

options		BLINK
## disable inlining __cpu_simple_lock()
## the locore version attempts to detect stuck locks
## not inlining saves about 60K on the kernel's text
options 	__CPU_SIMPLE_LOCK_NOINLINE

cpu* 		at mainbus0		# declare additional CPUs
cpu*		at cpuunit?

====================

On Mon, Nov 14, 2005 at 04:31:37PM -0500, Heitzso wrote:
> On a sparcstation20 w/ dual hypersparc 150s and 512M RAM,
> trying to compile a new kernel with ./build.sh,
> I ran into sbrk problems breaking the compile.
> This occurred at different places on subsequent attempts.
> 
> I googled around and saw references to the need to
> up NKMEMPAGES and/or NKMEMPAGES_MAX_DEFAULT
> in the kernel configuration file, but there's no default
> settings in GENERIC (2.1) so was skittish about trying to
> manipulate it there.
> 
> I saw references to changing vm.nkmempages w/ sysctl
> but that does not work, either by setting the sysctl.conf
> in etc. & reboot or by trying to write the value directly
> (I saw that it is rigged non-writable, but several emails floating
> around the web referred to using sysctl to do this so I
> tried anyway)
> 
> I also saw a reference to changing this value in param.h
> in the source tree.  I did not attempt this.
> 
> Could someone explain how this should be set on netbsd
> sparc 2.1 (or 3.0, I'll probably upgrade when it is released).
> 
> BTW, I rebooted with the new nkmempages setting in
> /etc/sysctl.conf and though that didn't do anything in
> that the nkmempages value stayed the same low value,
> I successfully ran a kernel compile then with only a
> single ssh session on the box.  I don't know if the reboot
> fixed some memory leak or if the 2 extra ssh sessions, one
> of which was running 'top', made a difference. 
> I was running top to monitor memory/swap/cpu usage
> during the compile .... there was no obvious memory
> loss during the compile, but then I didn't have my eyes
> on 'top' output right before the compile crashed (stopped
> with the sbrk memory failure).
> 
> Thanks,
> Heitzso

-- 
edoneel@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org