Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!timbuk.cray.com!equalizer!sdcrsi!network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com!karn From: karn@qualcom.qualcomm.com (Phil Karn) Subject: Re: strtod.c -- Where's the source Luke? Message-ID: <1992Sep18.221742.17382@qualcomm.com> Sender: news@qualcomm.com Nntp-Posting-Host: qualcom.qualcomm.com Reply-To: karn@chicago.qualcomm.com Organization: Qualcomm, Inc References: <8851@hq.hq.af.mil> <DJM.92Sep15104153@frob.eng.umd.edu> <1992Sep18.154311.20396@qualcomm.com> Date: Fri, 18 Sep 1992 22:17:42 GMT Lines: 27 In article <1992Sep18.154311.20396@qualcomm.com>, karn@servo.qualcomm.com (Phil Karn) writes: |> The default 386BSD file system allows only 5 megabytes of disk space |> for a swap area, and this is apparently too small for large compiles. |> Last night I regenerated my 386BSD system with 50 megabytes of swap |> space, and compiles that previously bombed now work (or at least they |> don't bomb with signal 6s!) I forgot to add that you also need to change the resource limits to actually get at those extra megabytes. The default #defined in /sys/i386/include/vmparam.h is 6 megabytes for the data segment soft limit and 32 meg for the hard limit. So an unprivileged user can raise his soft limit as high as 32 meg by saying "ulimit -d 32768" in his ..profile (this is for bash, for csh you'd say "limit datasize 32768" in your .cshrc). Going higher apparently requires modifying vmparam.h and building a new kernel; note that some other constants assume certain limits on the size of a process, so you may have to change them too. Having struggled with DOS for years (yes, even on the 486) probably no other thing gave me as much pleasure recently as booting 386BSD and running a test program that successfully malloc'ed a 16-megabyte chunk of memory... Phil