Generic 32 bit kernel should be compiled with 64 GB memory support

Bug #116842 reported by Fredrik

This bug report was converted into a question: question #31506: Generic 32 bit kernel should be compiled with 64 GB memory support.

22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu
Invalid
Undecided
Unassigned

Bug Description

Today, it is not unusual that desktop machines have more than 4 GB of ram.

I think that the generic 32 bit kernel should have 64 GB memory support like the server version.

Not all can/want to run the 64 bit kerlen (lots of things doesn't work if you do) and the server kernel can not be used in combination with restricted modules (unless compiling yourself).

An alternative could be yet another kernel version.

Revision history for this message
rozen (don-rozenberg) wrote :

I just upgraded my memory to 4GB and am very disappointed that the kernel only recognizes 3GB. With cheap memory and the growing popularity of virtual machines, I think it is important that Ubuntu support the larger memory sizes.

I am going to try the server version, but if it will not support restricted modules as suggested above, then I will not be able to use the nvidia driver and without that my generic kernel does not support ¨suspend to RAM¨.

This is a very unsettling situation. This is a very basic hardware support issue.

Revision history for this message
Fredrik (fredrk) wrote :

Still no 4GB+ support in Gutsy.

There SHOULD be a desktop-version of the kernel supporting HIMEM64G (64 GB memory).

Revision history for this message
Nanley Chery (nanoman) wrote :

Sorry, but this is not technically possible - if it was it would have been implemented a long time ago. The only way to get 4GB ram support is to use a 64-bit OS.

Revision history for this message
Fredrik (fredrk) wrote :

Not at all impossible.

The kernelconfig is:

HIGMEM64G
and
HIGHMEM

Ubuntu Server is compiled with both these flags but not the desktop version.

Using more than 4 GB ram has NOTHING to do with 32 vs 63 bit OS. Sure, one process can use more than 4 GB ram but that is no big issue (yet).

Revision history for this message
Fredrik (fredrk) wrote :

Here is it in Brainstorm:

http://brainstorm.ubuntu.com/idea/1553/

Any comment?

Revision history for this message
Fredrik (fredrk) wrote :
Revision history for this message
Fredrik (fredrk) wrote :
Revision history for this message
Fredrik (fredrk) wrote :
Revision history for this message
Stéphane Magnenat (stephane.magnenat) wrote :

This bug seems to be a duplicate of bug #156804.

Revision history for this message
Fredrik (fredrk) wrote :

More like bug #156804 is duplicate of this.

Revision history for this message
trollord (trollenlord) wrote :

Compiling kernel with PAE support indeed gives the 32-bit kernel ability to use 64 gigabytes of memory. However, single processes can still use only max 3 gigabytes. There will be 3-6% performance hit for memory operations. The worst part is that non-PAE supporting hardware will fail booting with the kernel. That is a blocker for making PAE kernels default.

In any case, if you need more, switch to 64-bit platform. You can still run 32-bit applications there if you must by using compatibility libraries. They do work.

Revision history for this message
Christoph Lechleitner (lech) wrote :

>non-PAE supporting hardware will fail booting with the kernel

Ouch, I admit that hurts.

Especially for non-x64-hardware where you have no "workaround" in switching to the amd64 distro.

I guest PAE cannot be "loaded" lateron or switched active with a kernel line parameter?
So what's left is either to eventually provide a some "generic-bigmem" kernel (and all the accompaning packages, especially several module packages for GPUs, WLAN cards, ...).

Revision history for this message
Fredrik (fredrk) wrote :

How about a PAE-enable kernel as option after installation?

The bug sure isn't invalid.

Revision history for this message
trollord (trollenlord) wrote :

>How about a PAE-enable kernel as option after installation?
>The bug sure isn't invalid.

It exists already. It is the server kernel.

Revision history for this message
Christoph Lechleitner (lech) wrote :

>>How about a PAE-enable kernel as option after installation?
>>The bug sure isn't invalid.

>It exists already. It is the server kernel.

At the time we came up with this issue (feisty), several module packages had not been available for the -server kernel, therefore some things (especially GPUs and WLAN cards) could not have been run easily on a server kernel ;-((

This did not change with gutsy, but with hardy seems to have changed.
Was there an official change in the policies regarding e.g. the linux-restricted-modules and kernel packages?

Anyway, did anybody actually try to use e.g. nvidia-glx-*, fglrx*, ... together with hardy's server kernel?

Revision history for this message
Fredrik (fredrk) wrote :

Does the server kernel has any other differences like timeslice length etc?

Revision history for this message
trollord (trollenlord) wrote :

Extra special needs non-corforming with the baseline users - instructions about the advanced situations for the newbies please.

Revision history for this message
Andy (andy-xillean) wrote :

So why is it in Debian 4 (etch) i can do this

apt-get install linux-image-bigmem.

And also in older versions of Ubuntu.
Why is now that we are forced to use a 64bit kernel with workstation workloads and wrestle with
flash ans skype and all those things.. Why not at least put a linux-image-bigmem kernel like
Debian does and older versions of Ubuntu had. ? Why? Is there any reason to refuse to
provide a linux-image-bigmem kernel in the repositories?

Revision history for this message
Andy (andy-xillean) wrote :

Compiz does not work with the server kernel and install nvidia drivers from the website complains about
installing the drivers on a xen kernel even though I installed linux-image-server. What gives?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.