Andrew Gallatin wrote:
>
> I have a user with a need to run a machine in varying memory
> configurations. The machine has 512MB & she needs to artificially
> constrain memory to multiples of 32MB from 32MB to 512MB. (32MB, 64MB,
> 96MB, 128MB ...)
>
> I was planning on having her edit /kernel.config & change the value of
> iosize npx0 and have the bootloader do a
>
> load -t userconfig_script /kernel.config
>
> at boottime.
>
> However, this feature appears to be broken in current. The
> resource_int_value() call which grabs msize is returning ENOENT &
> we're seeing the full 512MB of ram.
>
> Is there any way around this, short of building her 16 different
> kernels?
The npx0 tuneing hack has been broken for ages and never worked well anyway.
Originally, it depended on dset working, because by the time userconfig
ran, memory had already been sized and set up and it was way too late.
However, dset would modify the kernel binary so that next time it ran
the changes would be available early enough.
Now it's even worse since the resource_* routines use the config(8)
generated tables (see config.c) until malloc is up and running and then
it switches over to using malloc for backing.
Personally, I think we should use a kernel environment variable passed in
from loader, since kern_envp is available *real early*, from the very
beginning of init386(), which is called form locore just after going
virtual. It needs a couple of tweaks to get this to work, and in
particular, the environment variable will have to override the VM86
calls.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
