Different memory size detection of kernel and /proc/meminfo

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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html