I am trying to install tumbleweed i586 on a virtual machine (Qemu) with 8 GB RAM allocated to the VM. After completing the installation process and booting, the “top” command shows only 2 GB of total RAM. Same with free -h. When I checked the kernel, it shows PAE is enabled. It appears to be enabled by default but is unable to access the full amount of RAM. I tried re-installing with a virtual console open this time. The first line of the loader script shows the total RAM available is nearly 3 GB. How to solve this problem? Is it a bug in the installer that the boot kernel is 32 bit without PAE enabled. So the system thinks that it is installing on a 3 GB machine. After installation it does not matter whether the PAE is enabled or not because the OS itself installed on a 3 GB hardware. Please let me know if I am missing something.
Thank you @malcolmlewis . I am new to Opensuse tumbleweed. Can you please share a link to a knowledge base or any developer notes on how to build your own kernel in opensuse?
commit bbeb69ce301323e84f1677484eb8e4cd8fb1f9f8
Author: Arnd Bergmann <arnd (at) arndb.de>
Date: Wed Feb 26 22:37:09 2025 +0100
x86/mm: Remove CONFIG_HIGHMEM64G support
HIGHMEM64G support was added in linux-2.3.25 to support (then)
high-end Pentium Pro and Pentium III Xeon servers with more than 4GB of
addressing, NUMA and PCI-X slots started appearing.
I have found no evidence of this ever being used in regular dual-socket
servers or consumer devices, all the users seem obsolete these days,
even by i386 standards:
- Support for NUMA servers (NUMA-Q, IBM x440, unisys) was already
removed ten years ago.
- 4+ socket non-NUMA servers based on Intel 450GX/450NX, HP F8 and
ServerWorks ServerSet/GrandChampion could theoretically still work
with 8GB, but these were exceptionally rare even 20 years ago and
would have usually been equipped with than the maximum amount of
RAM.
- Some SKUs of the Celeron D from 2004 had 64-bit mode fused off but
could still work in a Socket 775 mainboard designed for the later
Core 2 Duo and 8GB. Apparently most BIOSes at the time only allowed
64-bit CPUs.
- The rare Xeon LV "Sossaman" came on a few motherboards with
registered DDR2 memory support up to 16GB.
- In the early days of x86-64 hardware, there was sometimes the need
to run a 32-bit kernel to work around bugs in the hardware drivers,
or in the syscall emulation for 32-bit userspace. This likely still
works but there should never be a need for this any more.
PAE mode is still required to get access to the 'NX' bit on Atom
'Pentium M' and 'Core Duo' CPUs.
If you have evidences and compelling arguments that this option is still needed, you need to contact developers.
inix is reporting that your processor supports the pae extensions. That has nothing to do with if the kernel will use them.
You then show that there is only 4G ram available anyway so you wouldn’t know either way.
Then you show that the kernel is named PAE. That doesn’t mean really anything. If they stopped producing a package named -pae, you wouldn’t be able to automatically upgrade kernels. You can put any flag you want in the config, if the source doesn’t act on it, it doesn’t mean anything.
The actual commit that removed it has already been linked in the thread. I have no idea what you’re trying to argue against.
Thanks for the detailed explanation. The only compelling argument is entirely personal, i.e. I have a few servers, Proliant ML 150 Gen1 with 2 Xeon CPUs on the motherboard and an IBM server with exactly same hardware configuration. They are equipped with 12 GB RAM each. However it may not a convincing argument for the developers as they have to look at a broader picture.
@mhurron , I agree with your explanation. However I want to know if the source itself has dropped the HIGHMEM64G option (i.e. no header files and modules) or the compiled kernel does not have this option even though if one wants, he/she can get this configuration by passing the appropriate flags. I understand that if I compile a custom kernel, I have to keep compiling it everytime a new kernel is available.
@malcolmlewis , thanks for sharing the knowledge base. It appears to be some work for sure but not very difficult if carried out with discipline. However, as @mhurron mentioned, the source itself probably does not have this option.
As kernel-pae has CONFIG_X86_PAE enabled, commenting out this code (which was the second effect of the CONFIG_HIGHMEM64G) should allow access to memory above 4G.
I would even go further and argue that condition
#ifndef CONFIG_HIGHMEM64G
should have been replaced with
#ifndef CONFIG_X86_PAE
because that is what the code actually does. And that may be accepted by developers.
If you look at the code you will see that there is no option to override this artificial restriction. But you may raise it up with kernel developers. It does sound like a bug.
Well, in principle nothing. But in reality, a lack of in-depth knowledge on my part. Probably the forums exist only for this reason. Thanks for the detailed explanation. I will try to understand your explanation.