generic kernels should support 4 GB RAM

Bug #156804 reported by Christoph Lechleitner on 2007-10-24
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-meta (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-generic

For some months now developer machines (desktop and laptop) are available and bought with more than 2 GB of RAM, say 4 GB.

Unfortunately, the -generic kernel of Ubuntu x86 only uses up to 3 GB (at least that's /proc/meminfo tells), which is unsatisfying.

As the -server kernel of the very same distribution does support 4 GB, this seems to be a kernel option issue.
After a look in /boot/config* I believe the key options are CONFIG_PAE and/or CONFIG_HIGHMEM64G which are set to no or not at all for -generic.

I believe this options should be enabled for -generic also.
(This is obviously a wish, not a bug)

Remark 1:
As CONFIG_HIGHMEM4G is set to yes in -generic kernel, it might be that the kernel uses the 4th GB, for kernel space only (I once found a bigmem discussion that suggested this special memory split for 4 GB situations). Assuming this is true, sharing all 4 GB dynamically still would be better.

Remark 2:
Most of the new "common" 4 GB machines are amd64 capable, so one might suggest using the amd64 distribution.
Unfortunately, many 3rd party applications are not available for amd64, and the ia32/linux32 subsystem is far from complete (yes, I'd like all libs beeing doubled), so this is not a real option, not even for servers where >4 GB are common for some time now, even on pure 32bit CPUs.

Remark 3:
Some manufacturers, including the "small" company continueing big blue's ThinkPad series, had obvious problems writing correct firmware for recent intel chipsets or don't know of PAE at all (or both) and therefore officially (!) (on their 4 GB laptops' product data sheets) claim that 32bit operating systems in general could only use 3 GB.
I laugh at that now ...

Steven Hildreth (sphildreth) wrote :

+1 vote on making this happen. I also have a workstation with 4GB ram that I would like to fully utilize on the 32bit generic kernel.

Eric Work (ework) wrote :

+1 vote! Another option would be to include the nvidia restricted driver in the server kernel.

Christoph Lechleitner (lech) wrote :

Most restricted drivers are available es extra package, in versions sepcifically compiled against specific kernels.
(nvida-glx-legacy, nvidia-glx, nvidia-glx-new)

Putting restricted nvidia modules in the kernel will not happen and for good reasons:
+ the kernel should be kept small, It's awful big as it is.
+ no one wants to taint the 100% GPL kernel with questionable closed-source binary garbage.
+ there are several different versions of the nvidia kernel modul, all with the same name. this is because nvidia maintains 3 or 4 generations of it's driver (7xxx, 9xxx, 11xxx, 1xx.11.x, ...). there are even modules not needed always, e.g. nv_agp.

Eric Work (ework) wrote :

Christoph,

I understand all that, my comment was worded wrong I guess. What we need is a build of the restricted drivers package for the -server kernel. There appears to be one for all others. Yes they do have packages for the individual drivers but you have to use module-assistant and have the module source package to build them. The nvidia-glx-* packages are just the userspace libraries I believe. Also there is no madwifi module-assistant compatible package and the atk5k driver doesn't support my card (Fedora includes 2.6.23, maybe 2.6.24 is better). I see a couple of solutions:

1. Enable the HIGHMEM_64G option in -generic.
2. Build restricted drivers for -server.
3. Build a special -pae kernel if systems with low memory or older CPUs for problems with PAE support for some reason (Fedora does this).
4. You can of course run 64-bit but there are still a few issues in terms of compatibility and also lesser common 32-bit libraries are not available.

I think #1 would be best, #3 would be a lot of work, and #4 is a workaround.

Not rambling just observations.

-Eric

Christoph Lechleitner (lech) wrote :

Ah, that you meant.

The server kernel will never get X11 support ;->>

I used the server kernel (and nvidia's own installer) for some time myself, but that's really not the way it should be.

I agree with your solution list and that #1 is the favourite.

However I'd generally love to see more complete and better 64/32 bit compatibility work, because I sometimes do things that are impossible to do with 32bit software.
Like:
+ opening a >2GB text file with gvim ;-)
+ rendering PDFs and HPGL files where the pixel representations becomes larger than 2GB

Obviously, some "small poor companies" like Adobe, Google, Opera, Skype, RealMedia, ... really need to start providing 64bit binaries!!!

TerryG (tgalati4) wrote :

Triaged to Confirmed. It's a known fact that 32-bit Linux only supports around 3.2 GB of RAM. 64-bit is missing some applications, but is getting better supported all the time. Not sure what Ubuntu can do about it. I imagine the changes to the 32-bit kernel are not trivial to support 4 GB of user space.

Changed in linux-meta:
status: New → Confirmed
Christoph Lechleitner (lech) wrote :

>It's a known fact that 32-bit Linux only supports around 3.2 GB of RAM.
???

With PAE and HIGHMEM_4G/HIGHMEM_64G enabled and compiled for i686 or higher, a 32-bit Linux can see 4 GB resp. 64 GB without problems.
(One could of course argue that these kernels are not "pure" 32-bit)

In some PAE articles I fell over months ago, there were success reports for using 8 GB on some 32bit servers (HP or Dell I believe), and I can confirm 4 GB for a pure 32bit Dell 2600 running SuSE 9.2 with a kernel called 2.6.8-24.25-bigsmp.
Obviously, cracking the 4 GB barrier requires certain things (address lines, PAE support, ...) from CPU, mainboard, memory and BIOS, but just a obviously there are 32bit servers fullfilling these requirements.

And we still want HIGHMEM_64G for -generic kernels for using it on Desktops and Laptops, because the application situation for 64-bit is still far from satisfying, due to some large firms' ignorance (which might be broken by Microsoft's 64-bit-only policy for W2k8+).

A precompiled firefox-ia32 package (and a bunch of firefox-plugin-*-ia32 packages) for the amd64 distro could provide a workaround for the most annoying lacks of amd64 ubuntu, but the increased memory usage of 64-bit binaries still recommends using a 32-bit distro.

I would also like to see PAE enabled in default kernel. In my case, I'm doing a lot of coding and I'm synchronizing my data between my desktop machine (core 2, x86-64, 4 GB RAM) and my laptop (Pentium 4M) so it was too inconvenient to install a 64 bits version ; yet I would like to use all my RAM. Furthermore, having more physical memory than address space ensure that no program can exhaust the memory of the computer, which is a nice feature ;-)

Christoph Lechleitner (lech) wrote :

For the record:
After all one 3rd party software company learns 64 bit compilation:
In the developer snapshot area ...
  http://my.opera.com/desktopteam/blog/
... Opera provides a 64 binary package for several Linuxes including Ubuntu.

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

Other bug subscribers