Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm running Debian Squeeze (x64):

# uname -srvmo
Linux 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux

I have 2 compatible 2 GB sticks of DDR2 in my G31M-S motherboard. It supports up to 8GB:

enter image description here

Since this is a server, I don't really care about graphics. So I set it to the lowest.

Internal Graphics Mode Select: Auto
                               Enabled, 1MB   <--
                               Enabled, 8MB
DVMT Mode Select:              Fixed Mode     <--
                               Auto
    DVMT/FIXED Memory:         128MB          <--
                               256MV

enter image description here

However, Linux is only detecting 3.19GiB of memory:

# cat /proc/meminfo
MemTotal:        3350712 kB
...

Looking at the E820 map:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cfdb0000 (usable)
[    0.000000]  BIOS-e820: 00000000cfdb0000 - 00000000cfdc0000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cfdc0000 - 00000000cfdf0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cfdf0000 - 00000000cfe00000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff380000 - 0000000100000000 (reserved)
[    0.000000] DMI present.
[    0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

And doing a little math:

>>> ((0x9F800 - 0x10000) + (0xCF6B0000 - 0x100000)) / 1024.0 / 1024.0 / 1024.0
3.240476608276367

We get just about the same answer.

What am I missing?


I'm not completely buying the "PCI address space" argument. Taking one of the two 2GB sticks out, the setup screen shows 2048MB.

# cat /proc/meminfo
MemTotal:        2058432 kB

That's 1.96GB.

E820 map again:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000007fdb0000 (usable)
[    0.000000]  BIOS-e820: 000000007fdb0000 - 000000007fdc0000 (ACPI data)
[    0.000000]  BIOS-e820: 000000007fdc0000 - 000000007fdf0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000007fdf0000 - 000000007fe00000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff380000 - 0000000100000000 (reserved)
[    0.000000] DMI present.
[    0.000000] AMI BIOS detected: BIOS may corrupt low RAM, working around it.
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

And the math...

>>> ((0x9F800 - 0x10000) + (0x7fdb0000 - 0x100000)) / 1024.0 / 1024.0 / 1024.0
1.9973125457763672

So I got 2GB / 2GB. /proc/cpuinfo shows that my processor supports 36-bit physical addressing. 2^36 = 64GB, which I'm not event close to.


# ./smem -R 4G -w
Area                           Used      Cache   Noncache
firmware/hardware            843592          0     843592
kernel image                      0          0          0
kernel dynamic memory        181116     134616      46500
userspace memory             287784      19736     268048
free memory                 2881812    2881812          0
share|improve this question
    
Make sure memory remapping is ON in the BIOS. –  David Schwartz Jul 25 '12 at 9:31
    
@DavidSchwartz I tried turning that on, and the kernel panicked on boot. I may try that with a live CD though. –  Jonathon Reinhart Jul 25 '12 at 13:57
    
@DavidSchwartz You are absolutely correct. Turning on memory remapping seems to have done the trick. Without it turned on, Memtest86+ reports ~3300 MB. With it turned on, it reports 4086 MB. If you make that an answer, I will gladly accept. –  Jonathon Reinhart Aug 22 '12 at 4:06

3 Answers 3

up vote 3 down vote accepted

You need to turn Memory Remapping ON in the BIOS. Otherwise, it won't remap memory above the 4GB boundary and some memory will be covered up by hardware mappings.

share|improve this answer
    
This was the problem. Turning on memory remapping seems to have done the trick. Without it turned on, Memtest86+ reports ~3300 MB. With it turned on, it reports 4086 MB. –  Jonathon Reinhart Aug 22 '12 at 14:24
    
Same, before enabling Memory Hole Remapping (AMIBIOS), the POST would report approximately 3.3 GiB, while DMI would still list two modules of 2 GiB each. –  njsg Aug 28 at 18:23

PCI also uses some of the address space. Both PCI cards and PCI devices build into the motherboard (such as the chipset).

Usually this meant that out of 4GB only 3¼ to 3½ GB was available, even if you did not use a modern GPU with a lot of onboard RAM.

share|improve this answer
    
I pretty much ignored that fact... I mean 0.8GB? However, the top of the e820 map is 0x100000000 == 1<<32, which is interesting. So why is the BIOS not mapping the rest of the RAM above 1<<32 ? It's a Celeron E3400, and /proc/cpuinfo says address sizes : 36 bits physical, 48 bits virtual That should be good for 64GB. ((1<<36) / (1024*1024*1024) == 64) –  Jonathon Reinhart Jul 25 '12 at 0:27
    
The manual for my old Tyan motherboard is the only one which seemed to warn me that though it supported 4GB RAM, it would never expose all of that to the OS. Depending on the used expansion cards (plain old PCI, 66Mhz, 64bit) it would expose about 3.3GB usable space. I never got to test that, 512MB RAM was all I could afford. (This was back when this dual CPU motherboard still meant using two physical CPUs. Things might have changed since then and PCIe might not have the same limit. But most motherboards still have both PCI and PCIe). –  Hennes Jul 25 '12 at 0:35
    
See my edit. I think the problem is that the either the BIOS refuses to report any memory about 1<<32, or this kernel doesn't know how to understand it. –  Jonathon Reinhart Jul 25 '12 at 0:38
    
Did you consider the shared memory used by your internal graphics? If you have smem installed, try smem -R 4G -w for a general overview of available/used memory. –  Izzy Jul 25 '12 at 8:30
1  
@Hennes This answer would make perfect sense if this were a 32-bit system. But not for 64-bit (with 36-bit physical memory addressing). –  Jonathon Reinhart Jul 25 '12 at 15:36

Your missing RAM is used by the firmware:

# ./smem -R 4G -w
Area                           Used      Cache   Noncache
firmware/hardware            843592          0     843592
kernel image                      0          0          0
kernel dynamic memory        181116     134616      46500
userspace memory             287784      19736     268048
free memory                 2881812    2881812          0

Summing up:

echo $((181116 + 287784 + 2881812 + 843592))
4194304

So you see, it sums up to 4GB. And here's the ~ 800M you report missing:

firmware/hardware            843592          0     843592
share|improve this answer
    
Yes, and I'm not surprised by that. The question is, why isn't the BIOS reporting that 800MB of ram above 0x100000000 (1<<32) ? It's behaving as if it were a 32 bit system. –  Jonathon Reinhart Jul 25 '12 at 14:28
    
Yes, I think this answer is valid, but that final question remains :-) –  Jonathon Reinhart Jul 25 '12 at 14:34
    
So what does smem -R 2G -w say with just 2G in the machine (especially concerning the firmware/hardware, as that seems to be the section where the "missing 800M" went with 4G)? Would be quite funny if the firmware suddenly no longer needs those 800M... –  Izzy Jul 25 '12 at 14:38
    
Could it have to do with AMI BIOS detected: BIOS may corrupt low RAM, working around it. -- and the Wikipedia remark (from your e820link) "Sometimes the BIOS is buggy and incorrectly reports the reserved memory. This can cause memory testing software, like Memtest, to report errors." ? EDIT: Ah, no -- that would just account for 64k, not 800M... –  Izzy Jul 25 '12 at 14:44
    
I can check when I get home, but I'm assuming it will say the same thing. Look at the E820 map for 2GB. By observation, it looks roughly the same, except the reserved/ACPI ranges are lower in the addr space (some of them). –  Jonathon Reinhart Jul 25 '12 at 15:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.