Different memory size detection of kernel and /proc/meminfo
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Dear all,I'm having a strange problem with detecting the memory size correctly. I'm operating on a Q35 Chipset with 4 GB memory (2x2GB) and a x64 version of Etch installed. Booting with the latest kernel (22.214.171.124) following situation appears: While dmesg shows
Memory: 3983764k/5177344k available (3584k kernel code, 134048k reserved, 1579k data, 412k init)
/proc/meminfo reports MemTotal: 3988096 kB MemFree: 3829816 kB ...As you can see the kernel is reporting nearly 5 GB of memory while meminfo shows the correct value of nearly 4 GB installed. Passing the mem-option with "mem=4096M" to the kernel the following happens. dmesg reports
Memory: 3081068k/3135168k available (3584k kernel code, 53704k reserved, 1579k data, 412k init)
and /proc/meminfo also reports MemTotal: 3085400 kB MemFree: 2927196 kB ...So passing the "normaly" right value to the kernel results in a loss of 1 GB of memory. The difference of the first case wouldn't really mind me if there weren't problems with one PCI Card which isn't working correctly. In the first case it isn't operating correctly whereas in the second case it is working correctly. The only difference (beside of the memory size) I see is the behaviour of allocating the DMA32 Zone pages. Could that be the cause?
But back to the main problem. Beside the difference of memory and resulting the allocation of the dma pages, everything seems the same in case one and two. Looking at /proc/mtrr it gives me
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg02: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg05: base=0x13c000000 (5056MB), size= 64MB: uncachable, count=1 reg06: base=0xbf600000 (3062MB), size= 1MB: write-through, count=1for both variants. We there hell the 5056MB is getting from!? It nearly costs me the last 2 days of searching without any real solution. Could it be that this is a problem with the BIOS also? I just read some notes about the Memory Remapping Feature of some BIOSes, but mine doesn't seem the have such an option in BIOS.
Does anyone have a clue about it or know what the cause could be? Best, Fabian -- To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html