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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.