Ubuntu kernel doesn't support >=4GB memory

[Milad Fatenejad]

I recently upgraded to 4 gb of memory on my 3GHz Xeon computer. The the ubuntu memory test program (selected from the boot menu) and my bios report that I have 4 gb of memory.

However both the gnome-system-monitor and /proc/meminfo say that I have only 3.0 GB.

I was pretty sure when I bought the memory that I should be able to have up to 4 gb. I've searched around for solutions, and can't seem to find any.

Thank You
Milad Fatenejad

[Stéphane Graber (stgraber)]

I just checked the 2.6.17 kernel config file and it supports the memory up to 4GB, but maybe you have a little bit more so that option isn't enough and you would require the 64GB one.
I change the package to linux-2.6.17 and change the title.

[Stéphane Graber (stgraber)]

Moving to linux-source-2.6.17 package
Reason of the bug is confirmed so status confirmed as well.
Reason = CONFIG_HIGHMEM4G is enabled but not CONFIG_HIGHMEM64G which will cause some problem like this bug report.

[Brian Murray (brian-murray)]

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

[Eric Work (ework)]

+1 Vote!

[Jeremy Akers (irwinr12)]

I have the same problem in Ubuntu 7.10 with Kernel 2.6.22:

uname -a
Linux dell 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

I have four 1GB dimms installed. BIOS reports 4GB memory installed. However:

cat /proc/meminfo | grep MemTotal
MemTotal: 3106444 kB

Is there a 'High memory' kernel package or some such that can be installed without requiring the rebuild of the kernel? I am more than happy to go in and recompile, but then everytime a kernel update is released I would need to recompile and I could run into dependancy issues with my Nvidia drivers and such. So it would be highly preferred if there were an officially supported Ubuntu kernel package that offers support for at least 4GB of memory or more.

Anyone know if this will be an issue in 8.04 as well?

-Jeremy

[Sergio Zanchetta (primes2h)]

The 18 month support period for Edgy Eft 6.10 has reached it's end of life. As a result, we are closing the linux-source-2.6.17 Edgy Eft kernel task. However, please note that this report will remain open against the actively developed kernel. Thank you for your continued support and help as we debug this issue.

[Sergio Zanchetta (primes2h)]

Hardy Heron 8.04 was recently released. It would be helpful if you could test the new release and verify if this is still an issue - http://www.ubuntu.com/getubuntu/download . You should be able to test your bug using the LiveCD. Please let us know your results. Thanks.

[Jeremy Akers (irwinr12)]

I have a Dell XPS with 4GB memory installed, running 32-bit Ubuntu Hardy 8.04:

jeremy@dell:~$ uname -a
Linux dell 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

jeremy@dell:~$ free -m
             total used free shared buffers cached
Mem: 3033 2937 95 0 82 1866
-/+ buffers/cache: 988 2044
Swap: 3773 203 3569

jeremy@dell:~$ cat /proc/meminfo
MemTotal: 3106188 kB
MemFree: 76584 kB
Buffers: 85548 kB
Cached: 1915864 kB
SwapCached: 64228 kB
Active: 2570856 kB
Inactive: 203964 kB
HighTotal: 2226508 kB
HighFree: 53508 kB
LowTotal: 879680 kB
LowFree: 23076 kB
SwapTotal: 3863592 kB
SwapFree: 3655244 kB
Dirty: 34604 kB
Writeback: 20 kB
AnonPages: 772640 kB
Mapped: 1666920 kB
Slab: 165552 kB
SReclaimable: 137544 kB
SUnreclaim: 28008 kB
PageTables: 6260 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 5416684 kB
Committed_AS: 1864320 kB
VmallocTotal: 114680 kB
VmallocUsed: 58192 kB
VmallocChunk: 52472 kB

If I install the linux-server kernel package, I can see all 4GB of memory, but I had issues running vmware player with linux-server kernel, so I had to switch back to the standard desktop kernel which only sees 3GB of memory.

Since the system is 32 bit either way, the difference has to be from an option such as HIGHMEM or some other memory setting in the default Ubuntu kernel not being switched on. With more and more desktops/workstations including 4+ GB of memory today, this option really should be on by default on the 32 bit installs.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Daniel T Chen (crimsun)]

-server supports 4GB.

[Jeremy Akers (irwinr12)]

Yeah, we know it works on -server. But we're not running servers. The -server kernel is geared toward servers and we should not have to use a server oriented kernel just to use more than 3GB of RAM.

[Andy Whitcroft (apw)]

A knotty problem. The i386 -generic kernel is limited to 4GB of physical address space. Commonly systems with 4GB or more will have the memory placed such that there is a physical hole from 3GB to 4GB and the remaining memory above that. Thus a 4GB system will commonly occupy 5GB of physical address space and the -generic kernel cannot address the final GB and so it is not seen or used.

To enable access to this memory the HIGHMEM64G config option is required, but this option enables PAE which comes with some cost. The -server kernel does have this enabled, but this is configured very slightly differently to optimise it for non-interactive use. The amd64 -generic kernel is not affected by this issue.

The current options basically are:

1) only use 3GB of ram (annoying),
2) run the -server kernel (not 100% optimal), or
3) run the amd64 -generic kernel.

The differences between the -generic and -server kernel are small and this is likley to be the best compromise in the short term. I will start the discussion on how we might offer a kernel better suited to these systems as 4GB of ram is becoming more common.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Leann Ogasawara (leannogasawara)]

Just closing this against linux-source-2.6.22 as it will reach it's end of life in approximately a week from now and it's unlikely a Stable Release Update to 2.6.22 will be made for this before then. However, please note this does remain open against the actively developed kernel. Thanks.

[Fredrik (fredrk)]

Adding a new flavor -genericbigmem is the only good solution i think.

[Fredrik (fredrk)]

The new flavor should be used if the installer detects more than 3 GB ram. Also, if ram is upgraded, Ubuntu should suggest a switch.

[Rich Wales (richw)]

This problem still exists in the Jaunty RC kernel (2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux).

IMHO, the default 32-bit desktop kernel should support 4GB (by enabling PAE) -- or if enabling PAE creates inefficiencies when it's not needed, then a separate PAE-enabled desktop kernel should be made available for those who would benefit from using it.

Telling people to use either the server kernel isn't a good solution because the server kernel is optimized for non-interactive computing. And telling people to use a 64-bit system isn't a good solution because some software doesn't run well (or at all?) on a 64-bit system.

[Rich Wales (richw)]

Again, I'm running the Jaunty RC (2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux) on a desktop with 4 GB. The BIOS reports 4GB on startup, but /proc/meminfo says it sees only 2838352 kB (2.75 GB).

I tried the Grub patch suggested in bug 189269 (http://www.howtoforge.com/make-your-xen-pae-kernel-work-with-more-than-4gb-ram-debian-etch-grub). The claim made there was that not all RAM was being seen, and that a small change to Grub (without doing anything to the kernel) fixed the problem.

However, this Grub patch didn't change anything for me -- Ubuntu still saw only 2.75 GB after rebooting with the new Grub in place on my disks.

Since the Grub patch was proposed in the context of the "Xen-PAE kernel", I'm going to guess that the kernel in this case was already PAE-enabled. So perhaps the reason the Grub patch did nothing for me is because I'm running a "desktop" system (and many people have said that the desktop kernel doesn't have PAE enabled). But I just wanted to put it on record that, in my case at least, this Grub patch does *NOT* give me access to any extra memory, and the problem still remains.

Given what others have said about a "server" kernel fixing the problem, I'm not sure what to make of the report that the Xen-PAE kernel wasn't seeing all the memory on the system, and that a patch to Grub was needed as well.

I would still recommend that a PAE-enabled version of the 32-bit desktop kernel ought to be made available for people who have >= 4GB of RAM on their desktops. The two workarounds proposed so far -- using a "server" kernel, or installing a 64-bit system -- seem to have their own problems and don't sound like good general solutions at this time.

[apjjr (alex-ourwoods)]

I've just installed a Intel DG35EC motherboard with an Intel Core 2 Duo E8400 3GHz processor and 4GB RAM now running Linux las 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux.
I was puzzled by the fact that only 3GB of memory was usable with the desktop 9.04 system. I "googled" and found this page. I also found the page at http://www.cyberciti.biz/faq/ubuntu-linux-4gb-ram-limitation-solution/. After a little more reading, I followed the instructions on the cyberciti.biz site. Installing the server kernel worked for me.

~$ free -m
             total used free shared buffers cached
Mem: 4015 396 3619 0 15 132
-/+ buffers/cache: 248 3767
Swap: 3867 0 3867

I'm too new at this to understand any caveats of using the server kernel on a desktop system, but I'm happy that I can utilize all of the memory that I paid for. I will be using this system for testing VMware and Virtualbox to try to get sco openserver 5.0.6 to run on newer hardware(wish me luck).
This should be fixed for the desktop install, as well. I'm just glad I could find a fix on the net and the server kernel works!
-Alex

[Imre Péntek (pentek-imre)]

hello, I am not sure if I report to the right place, but I have 4 gb (2x2GB) of ram (also lshw confirms that), but under any ubuntu (including 64 bit, 32 bit -server -generic, and howto here: http://www.kreno.be/2007/11/22/howto-ubuntu-4gb-memory-support/ ) I can see only ~3GB. top says: Mem: 3025656k total
imi@most:~$ free -m
             total used free shared buffers cached
Mem: 2954 827 2126 0 92 370
-/+ buffers/cache: 364 2590
Swap: 3906 0 3906
imi@most:~$ cat /proc/meminfo
MemTotal: 3025656 kB
MemFree: 2193276 kB
Buffers: 94804 kB
Cached: 379396 kB
SwapCached: 0 kB
Active: 435060 kB
Inactive: 296676 kB
Active(anon): 260248 kB
Inactive(anon): 8 kB
Active(file): 174812 kB
Inactive(file): 296668 kB
Unevictable: 40 kB
Mlocked: 40 kB
HighTotal: 2163980 kB
HighFree: 1516172 kB
LowTotal: 861676 kB
LowFree: 677104 kB
SwapTotal: 4000176 kB
SwapFree: 4000176 kB
Dirty: 60 kB
Writeback: 0 kB
AnonPages: 257652 kB
Mapped: 85436 kB
Slab: 40120 kB
SReclaimable: 28692 kB
SUnreclaim: 11428 kB
PageTables: 4828 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 5513004 kB
Committed_AS: 606120 kB
VmallocTotal: 122880 kB
VmallocUsed: 12692 kB
VmallocChunk: 103924 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 51192 kB
DirectMap2M: 858112 kB

dmesg:
[ 0.000000] BIOS EBDA/lowmem at: 0009d400/0009d400
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.28.9-custom (root@most) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #1 SMP Tue May 12 17:19:25 CEST 2009 (Ubuntu 2.6.28-11.42-generic)
[ 0.000000] KERNEL supported cpus:
[ 0.000000] Intel GenuineIntel
[ 0.000000] AMD AuthenticAMD
[ 0.000000] NSC Geode by NSC
[ 0.000000] Cyrix CyrixInstead
[ 0.000000] Centaur CentaurHauls
[ 0.000000] Transmeta GenuineTMx86
[ 0.000000] Transmeta TransmetaCPU
[ 0.000000] UMC UMC UMC UMC
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
[ 0.000000] BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000d2000 - 00000000000d4000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bb6a1000 (usable)
[ 0.000000] BIOS-e820: 00000000bb6a1000 - 00000000bb6a7000 (reserved)
[ 0.000000] BIOS-e820: 00000000bb6a7000 - 00000000bb7bc000 (usable)
[ 0.000000] BIOS-e820: 00000000bb7bc000 - 00000000bb80f000 (reserved)
[ 0.000000] BIOS-e820: 00000000bb80f000 - 00000000bb908000 (usable)
[ 0.000000] BIOS-e820: 00000000bb908000 - 00000000bbb0f000 (reserved)
[ 0.000...

[Imre Péntek (pentek-imre)]

hello again, as we searched for forums for the solution, we found that the problem might lie in a coincidence: I have an intel gma card, and this causes the same for several fedora users. blacklisting the intel_gma won't help.

[Imre Péntek (pentek-imre)]

I've seen ~3GB also under 64bit version, but anyways, in my case it's (assumably) an interference with intel-hda video driver.

[Andy Whitcroft (apw)]

As mentioned in comment #12 this is primarily triggered by the memory not all being below the 4GB physical boundary. The correct solution is to use a PAE enabled kernel. This was discussed at Karmic UDS and the flavours updated such that there is a generic and generic-pae kernel. These should be selected automatically based on the installed memory size. But if you are running i386 and not seeing all your RAM you should install linux-generic-pae and see if that fixes the issue. If it does not then you should file a new bug.

Closing this Fix Released as the original reporters issue was fixed in Karmic by that kernel.

[Imre Péntek (pentek-imre)]

I'm pretty sure I tried at least one pae enabled kernel at the time of my comment #20 (-server was pae enabled? anyways I also tried to switch to 64GB support by hand-compiling a kernel also)... by the way I also tried 64 bit ubuntu, but it also saw only ~3GB of my memory... maybe it's time to try lucid64 also.

[Christoph Lechleitner (lech)]

>by the way I also tried 64 bit ubuntu, but it also saw only ~3GB

I see no way a 64-bit distro falls short of using every RAM there is.
(Well maybe there are kernel params to restrict the RAM but I assume you have not done that)

IMO you either have only 3 GB, or your mainboard and/or BIOS lack support for more.