|
On 14.04.2011 19:30, Wick wrote: I think i got it now :)Hi, Andrzej Kardas: You're very close now. in my case: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) 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 interrupt INT 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@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. Yes, in my case internal graphic controller's RAM is situated above TOLUD:On 14.04.2011 17:09, Adrian Cornish wrote: Just a thought - lower end graphic cards use system RAM as their own dont they and@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: 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.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 :) 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 |
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
