# 4 GB ram on a 32-bit system

## evoweiss

Hi all,

I recently upgraded my memory on my old PC. I was wondering whether somebody could point me to a comprehensive guide my being able to access all 4GB of ram on a 32-bit system or, if possible, just tell me here and how to check.

Best,

Alex

----------

## toralf

I'm running here an 8 GB RAM system with a 32 bit Linux, it works fine AFAICT. The command free is your friend for a quick view.

----------

## khayyam

evoweiss ...

You will need to enable CONFIG_HIGHMEM4G in the kernel, if its not already, and the 3G/1G split (the default) is also probably what you want.

best ... khay

----------

## The Doctor

I believe that Linux is fairly good about seeing all 4 gigs of ram on 32 bit, however you would gain from installing  64 big. 4 gigs is the theoretical limit for 32 bits. You can get higher memory support on 32 bit, but it is a hack.

64 bit also includes access to more registers and better handling of some computationally intense processes. Given development focus  and performance enhancements, I would simply use 64 bit if you can.

----------

## evoweiss

Hi all,

 *khayyam wrote:*   

> You will need to enable CONFIG_HIGHMEM4G in the kernel, if its not already, and the 3G/1G split (the default) is also probably what you want.
> 
> 

 

Thanks for the speedy reply. 

First, I only have a 32 bit machine, so I don't think running a 64 bit linux system would make sense, unless they're something I'm missing. 

Second, CONFIG_HIGHMEM4G appears to be set to compile in the kernel.

The output of free -h is as follows:

```

             total       used       free     shared    buffers     cached                                                                                                                                      

Mem:          3.6G       2.1G       1.5G         0B       412M       1.3G                                                                                                                                      

-/+ buffers/cache:       368M       3.2G                                                                                                                                                                       

Swap:         494M         0B       494M                                                                                                                                                                       

Total:        4.1G       2.1G       2.0G

```

I take it this means it worked.

Best,

Alex

----------

## NeddySeagoon

evoweiss,

This means you can see about 3.6G of your 4G memory.  The rest has vanished under the memory mapped IO space.

You may be able to see the rest if you use HIMEM64G, however this is a hack, as the Doctor said.  

You still only have a 4G address space but now you have several of them.

The Physical Address Space Extension (PAE) is enabled, so you get 36 bit in the physical addresses but any process still has 32 bit pointers. 

Its paging by another name ... think expanded memory in early PCs.

I don't know if your system will map the RAM hidden under the memory mapped IO space to somewhere above 4G.  Thats required to be able to use it.

Its also required to boot with HIMEM64G set.

Keep your old kernel handy in case it doesn't work.

----------

## evoweiss

Hi,

 *NeddySeagoon wrote:*   

> 
> 
> This means you can see about 3.6G of your 4G memory.  The rest has vanished under the memory mapped IO space.
> 
> You may be able to see the rest if you use HIMEM64G, however this is a hack, as the Doctor said.  
> ...

 

I see... I tried doing this and the kernel booted fine. Xorg didn't start, but I imagine that I had to reinstall the nvidia drivers. It didn't seem to make a difference according to free -h.

Best,

Alex

----------

## NeddySeagoon

evoweiss,

Free is a 32 but program, it can only see the 32 bit address space it runs in.

This will always contain the memory mapped IO space and the kernel.

dmesg may say something useful.

If you don't get the use of the other 400MB RAM, its not worth the hoops the virtual memory manager has to jump through to use PAE.

----------

## evoweiss

Hi again,

 *NeddySeagoon wrote:*   

> 
> 
> Free is a 32 but program, it can only see the 32 bit address space it runs in.
> 
> This will always contain the memory mapped IO space and the kernel.
> ...

 

I'm not sure where I would look. The places I can see that might be relevant seem to suggest that it's made no difference. 

```

[    0.000000] Memory: 3764552k/3800528k available (2808k kernel code, 35528k reserved, 1190k data, 388k init, 2887128k highmem)

```

PAE is compiled in the kernel. Should it not be?

Anyway, if I can't get all of the memory, so be it. As you say, 400K is not enough to fuss about if it's to be a pain.

Best,

Alex

----------

## NeddySeagoon

evoweiss,

Its M not k.

Yes. PAE should be compiled in.

You may see something where the BIOS reports the memory map.  This is from a 64 bit system ...

```
[    0.000000] e820: BIOS-provided physical RAM map:

[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e3ff] usable

[    0.000000] BIOS-e820: [mem 0x000000000009e400-0x000000000009ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000000e6000-0x00000000000fffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cfe8ffff] usable

[    0.000000] BIOS-e820: [mem 0x00000000cfe90000-0x00000000cfea7fff] ACPI data

[    0.000000] BIOS-e820: [mem 0x00000000cfea8000-0x00000000cfecffff] ACPI NVS

[    0.000000] BIOS-e820: [mem 0x00000000cfed0000-0x00000000cfefffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000042fffffff] usable
```

If you have RAM above 4G, its worked, otherwise its not.

----------

## evoweiss

Here's what I see.

```

[    0.000000] e820: BIOS-provided physical RAM map:

[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable

[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved

[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000e7f73fff] usable

[    0.000000] BIOS-e820: [mem 0x00000000e7f74000-0x00000000e7f75fff] ACPI NVS

[    0.000000] BIOS-e820: [mem 0x00000000e7f76000-0x00000000e7f96fff] ACPI data

[    0.000000] BIOS-e820: [mem 0x00000000e7f97000-0x00000000e7ffffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fecf0000-0x00000000fecf0fff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fed20000-0x00000000fed8ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee0ffff] reserved

[    0.000000] BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved

[    0.000000] Notice: NX (Execute Disable) protection missing in CPU!

[    0.000000] SMBIOS 2.3 present.

[    0.000000] DMI: Dell Computer Corporation Dimension 8300               /0M2035, BIOS A02 07/21/2003

[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved

[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable

[    0.000000] e820: last_pfn = 0xe7f74 max_arch_pfn = 0x1000000

```

400 meg is still nothing to cry over.

Best,

Alex

----------

## NeddySeagoon

evoweiss,

There is nothing over 4G there.  Turn off HIMEM64G and go back to HIMEM4G as its faster.

----------

## evoweiss

Hi there,

 *NeddySeagoon wrote:*   

> 
> 
> There is nothing over 4G there.  Turn off HIMEM64G and go back to HIMEM4G as its faster.

 

Will do... no big loss. I'm still happy with the minor upgrade.

Thanks again.

Best,

Alex

----------

## chithanh

Some BIOSes have a memory remap option to move the memory from the PCI address space to the area above that. Google seems to indicate that Dell specifies 2 GB maximum memory for the Dimension 8300, which could mean that your BIOS is lacking this function.

----------

