Missing 1GB RAM, where is it? - SUMMARY

Sun Apr 17 03:58:22 EDT 2011

On 14.04.2011 19:30, Wick wrote:
> Hi, Andrzej Kardas:
>
> You're very close now.
I think i got it now :)

> To ensure that kernel detected your 4GB RAM, we need to check the stats:
> wick:~$ dmesg | grep Memory
> [    0.000000] Memory: 3716784k/4718592k available (5940k kernel code,
> 787332k absent, 214476k reserved, 5017k data, 956k init)
in my case:
dmesg | grep Memory
[    0.000000] Memory: 3013732k/3136000k available (4692k kernel code, 
120780k reserved, 2213k data, 576k init, 2224648k highmem)

after few hours of digging this topic i think this amount of RAM is 
correct, as almost everybody from this list suggested :). Here are 
results of my investigation:

At early start, when kernel boots and still working in real mode, actual 
memory map is taken from BIOS with use interruptINT 15h, AX=E820h. 
Result of this interrupt is dumped into ring buffer, so we can read this 
by dmsg. In my case:

[    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: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf680000 (usable)
[    0.000000]  BIOS-e820: 00000000bf680000 - 00000000bf700000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bf700000 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)

As we can see there are still 'holes' in addresses, similar to 
/proc/iomem. These holes are result of INT 15h, AX=E820h, this call 
return map of memory but with some limitations 
http://www.uruk.org/orig-grub/mem64mb.html):
*
1.* The BIOS will return address ranges describing base board memory and 
ISA or PCI memory that is contiguous with that baseboard memory.*
2.* The BIOS WILL NOT return a range description for the memory mapping 
of PCI devices, ISA Option ROM's, and ISA plug & play cards. This is 
because the OS has mechanisms available to detect them.*
3.* The BIOS will return chipset defined address holes that are not 
being used by devices as reserved.*
4.* Address ranges defined for base board memory mapped I/O devices (for 
example APICs) will be returned as reserved.*
5.* All occurrences of the system BIOS will be mapped as reserved. This 
includes the area below 1 MB, at 16 MB (if present) and at end of the 
address space (4 gig).*
6.* Standard PC address ranges will not be reported. Example video 
memory at A0000 to BFFFF physical will not be described by this 
function. The range from E0000 to EFFFF is base board specific and will 
be reported as suits the bas board.*
7.* All of lower memory is reported as normal memory. It is OS's 
responsibility to handle standard RAM locations reserved for specific 
uses, for example: the interrupt vector table(0:0) and the BIOS data 
area(40:0).

So thats why there is a hole for example: 00000000000a0000 - 
00000000000e0000 (point 6. Standard PC address range for VGA) and 
00000000c0000000 -00000000e0000000 (point 2. mapped PCI devices).
The main goal for OS is _NOT_ use memory ranges _NOT_ reported (holes) 
and reported memory ranges different than usable.

When it comes about so many RAM unavailable, about 1 GB in my case, the 
answer is in documentation 
(http://www.intel.com/design/mobile/datashts/309219.htm) of my 
northbridge chipset:

and at lpt:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML 
and 945GT Express Memory Controller Hub (rev 03)

It is not very sophisticated unit, because it is not able to remap 
memory from PCI range above 4 GB region. According to documentation:

"Addressing of memory ranges larger than 4 GB is _NOT_ supported."

So even my CPU is supporting 36bit physical addresses and PAE, memory 
controller is not able to remap memory from PCI range above 4GB range as 
other, more advanced chipset do with help of PAE.

I've also found:

"The (G)MCH does not remap APIC or any other memory spaces above TOLUD 
(Top of Low Usable DRAM). The TOLUD register is set to the appropriate 
value by BIOS."

So each access to memory above TOLUD is transfered to Southbridge or PCI 
express (which is directly connected to northbridge) or to the internal 
graphics device, TOLUD in my OS is 0xbf67ffffh = 3211263999 bytes, 
everything above it is unavailable for usage as RAM.

>> On 14.04.2011 17:09, Adrian Cornish wrote:
>>
>> Just a thought - lower end graphic cards use system RAM as their own
>> dont they
Yes, in my case internal graphic controller's RAM is situated above TOLUD:

and at lpt:~$ lspci -v -s 00:02.0 | grep Memory
     Memory at f0000000 (32-bit, non-prefetchable) [size=512K]
     Memory at d0000000 (32-bit, prefetchable) [size=256M]
     Memory at f0300000 (32-bit, non-prefetchable) [size=256K]

On 14.04.2011 19:30, Wick wrote:

> And about the memory hole in the /proc/iomem, I think it's related to
> kernel's resource management. Dig it in kernel source codes :)
Now i can say :) that, this regions (holes) are simply not available for 
system because they are above TOLUD and additionally not assigned to any 
device because I haven't particular device in PC for example bluetooth: 
I have space for it, but in my version of notebook was not available in 
standard equipment.

Many thanks everybody for suggestions and help with this, now I can 
assume that total RAM in my PC is correct. I also learned that 
documentation is standard point that I should aways start digging, it 
can save some time:)

--
regards
Andrzej Kardas
http://www.linux.mynotes.pl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110417/1ade3cf6/attachment-0001.html 