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 (2.6.25.10) 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=1

for 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

[Index of Archives]     [Linux Newbie]     [Audio]     [Hams]     [Kernel Newbies]     [Util Linux NG]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Device Drivers]     [Samba]     [Video 4 Linux]     [Git]     [Fedora Users]

  Powered by Linux