<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<small><br>
On 14.04.2011 19:30, Wick wrote:</small> <br>
<blockquote
cite="mid:BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com"
type="cite">
<pre wrap="">Hi, Andrzej Kardas:
You're very close now.<small>
</small></pre>
</blockquote>
<small>I think i got it now :)</small><br>
<br>
<blockquote
cite="mid:BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com"
type="cite">
<pre wrap="">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)<small>
</small></pre>
</blockquote>
<small>in my case:</small><br>
<small>dmesg | grep Memory<br>
[ 0.000000] Memory: 3013732k/3136000k available (4692k kernel
code, 120780k reserved, 2213k data, 576k init, 2224648k highmem)<br>
<br>
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:<br>
<br>
At early start, when kernel boots and still working in real mode,
actual memory map is taken from BIOS with use interrupt<small> </small>INT
15h, AX=E820h</small>. <small>Result of this interrupt is dumped
into ring buffer, so we can read this by dmsg. In my case:</small><br>
<small><br>
<small>[ 0.000000] BIOS-provided physical RAM map:<br>
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800
(usable)<br>
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000
(reserved)<br>
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf680000
(usable)<br>
[ 0.000000] BIOS-e820: 00000000bf680000 - 00000000bf700000
(ACPI NVS)<br>
[ 0.000000] BIOS-e820: 00000000bf700000 - 00000000c0000000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000
(reserved)<br>
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000
(reserved)</small><br>
</small><br>
<small>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
<a class="moz-txt-link-freetext" href="http://www.uruk.org/orig-grub/mem64mb.html">http://www.uruk.org/orig-grub/mem64mb.html</a>):<br>
<small><small><big><big></big></big></small></small></small><small><small><b><big><br>
</big>1.</b> The BIOS will return address ranges describing
base board
memory and ISA or PCI memory that is contiguous with that
baseboard memory.</small></small><small><small><b><br>
2.</b> 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.</small></small><small><small><b><br>
3.</b> The BIOS will return chipset defined address holes that
are not
being used by devices as reserved.</small></small><small><small><b><br>
4.</b> Address ranges defined for base board memory mapped I/O
devices
(for example APICs) will be returned as reserved.</small></small><small><small><b><br>
5.</b> 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).</small></small><small><small><b><br>
6.</b> 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.</small></small><small><small><b><br>
7.</b> 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).
</small></small><br>
<br>
<small><small><big>So thats why there is a hole for example: </big><small><big>00000000000a0000</big>
- </small><big>00000000000e0000 (point 6. Standard PC address
range for VGA) and</big> </small>00000000c0000000 -<small><small>
</small></small></small><big><small><small>00000000e0000000
(point 2. mapped PCI devices).<br>
The main goal for OS is _NOT_ use memory ranges _NOT_ reported
(holes) and reported memory ranges different than usable.<br>
<br>
When it comes about so many RAM unavailable, about 1 GB in my
case, the answer is in documentation
(<a class="moz-txt-link-freetext" href="http://www.intel.com/design/mobile/datashts/309219.htm">http://www.intel.com/design/mobile/datashts/309219.htm</a>) of my
northbridge chipset:<br>
<br>
and@lpt:~$ lspci <br>
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS,
943/940GML and 945GT Express Memory Controller Hub (rev 03)<br>
<br>
It is not very sophisticated unit, because it is not able to
remap memory from PCI range above 4 GB region. According to
documentation:<br>
<br>
"Addressing of memory ranges larger than 4 GB is _NOT_
supported."<br>
<br>
</small></small></big><small>So </small><big><small><small>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.<br>
<br>
I've also found:<br>
<br>
"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."<br>
<br>
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.<br>
<br>
</small></small></big><br>
<blockquote
cite="mid:BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">On 14.04.2011 17:09, Adrian Cornish wrote:
Just a thought - lower end graphic cards use system RAM as their own
dont they
</pre>
</blockquote>
</blockquote>
<small>Yes, in my case internal graphic controller's RAM is situated
above TOLUD:<br>
<small><br>
<big>and@lpt:~$ lspci -v -s 00:02.0 | grep Memory<br>
Memory at f0000000 (32-bit, non-prefetchable) [size=512K]<br>
Memory at d0000000 (32-bit, prefetchable) [size=256M]<br>
Memory at f0300000 (32-bit, non-prefetchable) [size=256K]</big></small><br>
</small><br>
<pre wrap="">On 14.04.2011 19:30, Wick wrote:</pre>
<br>
<blockquote
cite="mid:BANLkTik7g8vEf6X+suzwbXD1b4ow1__2xQ@mail.gmail.com"
type="cite">
<pre wrap="">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 :)
</pre>
</blockquote>
<small>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 </small><span
id="result_box" class="short_text" lang="en"><span title="Kliknij,
aby wyświetlić alternatywne tłumaczenia" class="hps"><small>equipment.<br>
</small><br>
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:) <br>
<br>
</span></span>
<pre wrap="">--
regards
Andrzej Kardas
<a class="moz-txt-link-freetext" href="http://www.linux.mynotes.pl">http://www.linux.mynotes.pl</a>
</pre>
<br>
<span id="result_box" class="short_text" lang="en"><span
title="Kliknij, aby wyświetlić alternatywne tłumaczenia"
class="hps"><br>
<br>
</span></span>
</body>
</html>