Subject: Re: Configuring kernel with multidisk swap
To: None <port-amiga@NetBSD.ORG>
From: Per Bojsen <pb@delta.dk>
List: port-amiga
Date: 02/19/1996 23:52:02
*** Regarding Configuring kernel with multidisk swap;
*** Bruce.Albrecht@seag.fingerhut.com (Bruce Albrecht) adds:
Bruce> You need to remove the "options GENERIC" line from your
Bruce> configuration if you want swap on more than one device. I
Bruce> think that was the only change I made when I went to two swap
Bruce> partitions.
*** Regarding Re: Configuring kernel with multidisk swap ;
*** "'Most Excellent' Eric Mehlhaff" <mehlhaff@crl.com> adds:
Eric> Its relatively simple, really:
Eric> make sure GENERIC is commented out of the kernel config file.
Eric> Then put in a config line for the partitions something like:
Eric> confg netbsd root on sd0a swap on sd0b and sd1b and sd2b
Yes, I already figured that out myself (as I pointed out in my initial
message ;-)), but it didn't help! Well, it allowed the build to
succeed but the resulting kernel fails to boot because the exec() of
init(8) fails with error ENOMEM (12).
However, I now think the problem is caused by something else than the
introduction of multi-disk swapping. I had been trying to increase
the MAXDSIZ and MAXTSIZ parameters from vmparam.h which determine the
hard limits for the maximum data segment and text segment sizes,
respectively. They are currently 32MB and 6MB, respectively. Are
there any obvious and/or known problems with increasing these? Is it
possible at all? Are there any limits to how large these can be? How
does their values affect performance in terms of memory usage and
kernel memory usage?
I was prompted to these experiments by Arthur Hoffmann's problems with
gdb on a postgres core dump. I have the same problems here and I
think gdb runs into the 32MB data segment size hard limit. The
postgres executable with debugging symbols is almost 10MB in size and
I watched the gdb process grow to at least 27MB in size. This was a
while before it exited with the `gdb: virtual memory exhausted: can't
allocate 8622656 bytes.' message.
--
Per Bojsen Email: pb@delta.dk
DELTA IC Design bojsen@moria.home.id.dtu.dk
Venlighedsvej 4, Hoersholm, Denmark