From Terry Singleton on Thu, 17 Dec 1998
When I run the admin tool "top" it appears as if my system is only using 64MB of memory.
11:00am up 4 days, 23:39, 2 users, load average: 0.07, 0.03, 0.00 40 processes: 39 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 0.3% user, 0.1% system, 0.0% nice, 99.6% idle Mem: 64168K av, 57420K used, 6748K free, 19820K shrd, 19816K buff Swap: 104384K av, 24K used, 104360K free 23932K cached
The results show 64168K av which indicates 64168K of available memory yet our system has 128MB RAM? I have the same results on 2 other Linux servers with more than 64MB RAM.
I am running RedHat 5.1, is there anything special I have to do to tell the system I have more than 64MB, recompile the kernel..?
This is a classic FAQ. The BIOS standards for memory query (Int 12h?) don't support the return of more than 64Mb of RAM. There are a number of different mechanisms for doing this on different chipsets, and some were "dangerous" (in the sense that they might hang some systems with a different API/BIOS). So, Linux didn't support automatic detection of more than 64Mb on most systems until very recently (2.0.36?).
You've always been able to over-ride this with a kernel parameter. As you may know from my earlier articles or from the LILO man pages you can pass parameters to the Linux kernel using an append= directive in your /etc/lilo.conf file (and subsequently runing /sbin/lilo, of course) or by manually appending the parameters on the command line at the LILO prompt (or on the LOADLIN.EXE command line).
To do this with lilo.conf you add lines of the form:
... to each of the Linux stanzas to which you want this to apply. (I'd leave one of them without it for the first try so you have a working configuration into which you can boot in case there's a problem with your system. I've heard of some cases where users had to reduce their memory configuration by 1Mb for odd reasons).
With the newer 2.0.36 and 2.1.x kernels you shouldn't need to do this (they have new autodetection code that should handle all of the common chipsets).
One trick for programmers --- if you want to ensure that your code or distribution will run in limited memory constraints you can do a quick test using a smaller mem= parameter to force the kernel to run in less space than it normally would.
WARNING: If you forget the trailing 'M' the kernel load will fail when it tries to allocate the specified amount of RAM in bytes. (Don't do that!).
In any event you might want to check out some of the FAQ's on Linux since I'm sure this is in a couple of them.
From Terry Singleton on Fri, 18 Dec 1998
Thanks Jim.I added the line as you suggested, however it did not seem to take am I supposed to be it under the boot image section itself? Memory is still 64000av.
Sorry, I should have been more detailed. You need to add this append= directive to each of the stanzas to which it applies. (You could have a couple of stanzas that referred to reduced memory configuration if you were a software developer, tester or reviewer so that you could test a package's behaviour under varying memory constraints).
This is what I have:
boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 append="mem=128M" image=/boot/vmlinuz-2.0.34-0.6 label=linux root=/dev/sda1 initrd=/boot/initrd-2.0.34-0.6.img read-only
should it be:
boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 image=/boot/vmlinuz-2.0.34-0.6 label=linux root=/dev/sda1 initrd=/boot/initrd-2.0.34-0.6.img read-only append="mem=128M"
(Also remember to re-run /sbin/lilo to read this config file and build the new boot blocks and maps therefrom).
Incidentally it would have been quicker and reasonably safe (in this case) to just try the experiement. It should have worked and you'd have gotten your answer much quicker.
I can understand a degree of hesitation about experimenting with the boot blocks and partition tables (a data structure that's stored in the the same block as the MBR first stage boot block). Obviously a mistake means that you can't boot at all.
However, it's wise to have a backup and a working rescue floppy and to practice using them before you make any changes to your /etc/lilo.conf.