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 thought I had 4 GiB of memory, but just to be sure, let's ask the BIOS about that:

ζ: sudo dmidecode --type 20
# dmidecode 2.12
SMBIOS 2.6 present.

Handle 0x000B, DMI type 20, 19 bytes
Memory Device Mapped Address
    Starting Address: 0x00000000000
    Ending Address: 0x0007FFFFFFF
    Range Size: 2 GB
    Physical Device Handle: 0x000A
    Memory Array Mapped Address Handle: 0x000E
    Partition Row Position: Unknown
    Interleave Position: Unknown
    Interleaved Data Depth: Unknown

Handle 0x000D, DMI type 20, 19 bytes
Memory Device Mapped Address
    Starting Address: 0x00080000000
    Ending Address: 0x000FFFFFFFF
    Range Size: 2 GB
    Physical Device Handle: 0x000C
    Memory Array Mapped Address Handle: 0x000E
    Partition Row Position: Unknown
    Interleave Position: Unknown
    Interleaved Data Depth: Unknown

Alright, 4 GiB it is. But I can't use all of it:

ζ: head -n 1 /proc/meminfo
MemTotal:        3913452 kB

Somehow, somewhere, I lost 274 MiB. Where did 6% of my memory go?

Now I know the address ranges in DMI are incorrect, because the ACPI memory map reports usable ranges well beyond the ending address of the second memory module:

ζ: dmesg | grep -E "BIOS-e820: .* usable"
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dee7bfff] usable
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000117ffffff] usable

I get pretty much the same info from /proc/iomem (except for the 4 kiB hole 0x000-0xFFF), which also shows that the kernel only accounts for less than 8 MiB.

I guess 0x00000000-0x7FFFFFFF is indeed mapped to the first memory module, and 0x80000000-0xDFFFFFFF to part of the second memory module (a bunch of ACPI NVS things live between 0xDEE7C000 and 0xDEF30FFF, and the remaining 16-something MiB of that range are just 'reserved'). I guess the highest 0x18000000 bytes of the second memory module are mapped above the 4 GiB mark.

But even then, there are two problems:

  • 128 MiB (0x08000000 bytes, living somewhere between 0xE0000000 and 0xFFFFFFFF) are still completely unaccounted for. To note, my graphics card is on PCI-Express and (allegedly) has 1 GiB dedicated memory, so that shouldn't be the culprit. Did the BIOS screw up in moving the memory, leaving it partially shadowed by MMIO?
  • Even with this mediocre explanation, I only 'found' 128 MiB. But /proc/meminfo is reporting a much larger deficit; where's the other 146 MiB? How does Linux count MemTotal?


I found something interesting:

[    0.000000] Memory: 3898660k/4587520k available (3643k kernel code, 542620k absent, 146240k reserved, 3126k data, 920k init)

Note that 4587520k is 0x0000000117ffffff (so 4 GiB plus 384 MiB), and 3898660k is that number with the 'absent' and 'reserved' memory subtracted. I'm not sure why dmesg reports 3898660k and /proc/meminfo reports 3913452 kB (a difference of 14792k).

I can account for the 542620k of 'absent' memory; it's 0xE0000000 - 0xFFFFFFFF (512 MiB) plus the 18 MiB reserved for ACPI data (0xDEE7C000 and on). The 146240k reserved memory is probably 'the other 146 MiB', although SI and binary prefixes might have gotten mixed up somewhere.

It still doesn't tell me much about the fate of either block of memory: where in the "absent memory" range did I lose 128 MiB, and what does Linux mean by "reserved memory"?


Just to see what would happen, I removed one of my memory modules.

ζ: dmesg | grep "BIOS-e820: .* usable"  
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ae7bfff] usable

System RAM now spans from 0x00000000-0x7bffffff, ignoring the gaps in low memory and the ACPI tables at the end. Now, 64 MiB is completely missing, rather than 128 MiB. I'm not sure whether this rules out that the BIOS is mistakenly reserving some kind of AGP aperture (I can't find any configuration option related to that in my BIOS).


ζ: dmesg | grep "kernel code"
[    0.000000] Memory: 1961780k/2013680k available (3643k kernel code, 396k absent, 51504k reserved, 3126k data, 920k init)
ζ: head -n 1 /proc/meminfo
MemTotal:        1976572 kB

So there is an additional deficit of 50-ish MiB thanks to the kernel.


Some clarification about the machine's specs.

This machine is a Sony VAIO laptop (VPC-EB1C5E). It's a consumer grade laptop. The BIOS, which is based on American Megatrends' Aptio, has very few configurable things (wall clock, password, boot order, disable VT-d and C3/C6 states). The advanced security features supported by the PCH (Intel HM55), being TXT and AT, seem unsupported by this laptop, so I doubt the BIOS is stealing memory to perform security tasks.

The processor is an Intel Core i5-520M. The graphics 'card' is an AMD Mobility Radeon HD5650 (with 1 GiB DDR3 memory), which lives on a PCI-Express bus.

The operating system is Debian jessie, using Linux 3.10-3-amd64.

Full E820 output by the kernel:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dee7bfff] usable
[    0.000000] BIOS-e820: [mem 0x00000000dee7c000-0x00000000deebbfff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000deebc000-0x00000000deeccfff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000deecd000-0x00000000deedefff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000deedf000-0x00000000deedffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000deee0000-0x00000000deee2fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000deee3000-0x00000000def10fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000def11000-0x00000000def11fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000def12000-0x00000000def14fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000def15000-0x00000000def16fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000def17000-0x00000000def1afff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000def1b000-0x00000000def1dfff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000def1e000-0x00000000def21fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000def22000-0x00000000def30fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000def31000-0x00000000dfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed10000-0x00000000fed13fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed18000-0x00000000fed19fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffbfffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000117ffffff] usable
share|improve this question
Have you accounted for addressing issues? Remember that RAM needs to store references to all existing memory blocks, and that might take that space. –  Doktoro Reichard Oct 24 '13 at 21:25
does your video card use shared memory? that would account for almost exactly the amount you are missing (eg 256MB for the vid card, and 18MB for kernal binaries). Note, no one ever gets a round number (straight power of 2) from \proc\meminfo. I've found a number of examples via web search and not only do they all show different values for similar or identical amounts of ram (per the label I mean). –  Frank Thomas Oct 24 '13 at 22:14
As noted in the question, my video card has (or is advertised to have) 1 GiB of dedicated memory. The driver acknowledges this figure. –  Rhymoid Oct 24 '13 at 22:54
@DoktoroReichard: that's accounted for in /proc/meminfo, as PageTables. It's 'only' 35 MiB. –  Rhymoid Oct 24 '13 at 23:31

2 Answers 2

I had a look at my 'dmesg' output. You grep yours so we can't see the whole thing but mine takes useable bits and reserves or removes them. Maybe you can't see that your system is doing the same?

[    0.000000] Linux version 3.2.0-54-generic (buildd@roseapple) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 (Ubuntu 3.2.0-54.82-generic 3.2.50)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-54-generic root=UUID=3db87ec9-02b7-4d47-93f2-0e4860750973 ro quiet splash vt.handoff=7
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bc6be000 (usable)
[    0.000000]  BIOS-e820: 00000000bc6be000 - 00000000bcebe000 (reserved)
[    0.000000]  BIOS-e820: 00000000bcebe000 - 00000000bcfbe000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bcfbe000 - 00000000bcfff000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bcfff000 - 00000000bd000000 (usable)
[    0.000000]  BIOS-e820: 00000000bd000000 - 00000000bfa00000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffd00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 000000023e000000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.6 present.
[    0.000000] DMI: Hewlett-Packard HP EliteBook 2560p/162B, BIOS 68SSU Ver. F.02 07/26/2011
HERE ->    [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
HERE ->    [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
share|improve this answer
I have those two lines as well. Those patches only apply to lower memory, so they take away less than 1 MiB. –  Rhymoid Oct 25 '13 at 16:26

If your BIOS supports it, you need to enable Memory Remapping.

See this question and accepted answer.

That 128MiB at 0xE0000000 is most likely used for memory-mapped PCI config space. This is an alternative to the conventional CF8h/CFCh (I/O) method for accessing PCI config space, and was added to accommodate the expanded config space brought about by PCI express.

If you post your whole E820 map, we could probably account for the rest of it.

Since several address space ranges (including ROM, MMIO PCI config space, MMIO hardware ranges, etc.) must be within the 32-bit address space, this shadows some of the actual memory that you have within that first 4 GiB. What remapping does, is it essentially moves some of that real RAM up above 0xFFFFFFFF, so that it can be used by the OS.

share|improve this answer
No, this is not the answer, because Memory Remapping already takes place. Before I posted the complete E820 map, you could already see that some of the physical RAM is remapped above the 32-bit boundary. My BIOS gives me no control over this, by the way. –  Rhymoid Dec 13 '13 at 16:38

Your Answer


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.