could it be a e820 related issue?

No, not really. The PCI address space and such must be mapped _somewhere_ within the 4 GB. There may be boards out there which - either remap the PCI address space above 4 GB - or remap the memory that has been shadowed by the pci addr space above 4 GB

The BIOS provides the following RAM map:

snippet from boot.msg:

<6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) <4> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 00000000dfe86c00 (usable) <4> BIOS-e820: 00000000dfe86c00 - 00000000dfe88c00 (ACPI NVS) <4> BIOS-e820: 00000000dfe88c00 - 00000000dfe8ac00 (ACPI data) <4> BIOS-e820: 00000000dfe8ac00 - 00000000e0000000 (reserved) <4> BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved) <4> BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved) <4> BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved) <4> BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) <5>2686MB HIGHMEM available. <5>896MB LOWMEM available.

So somewhere, I loose the memory right there.

Thanks,

Martin

...

thanks to all of you!

I have tried several different kernels. Configured with the 4/4GB split and with sparse/flat/disconigous memory model. Nothing helped. I could not find a BIOS settings to re-map the memory for the integrated peripherals.

Would anybody think, that disabling onboard NIC and sound and replacing them with PCI cards could help?

The slackware kernel which was previously installed (and saw the 4GB) does not even load on this computer anymore (maybe because it doesn't like suse ;) ) . I could not find out which mainboard is built in. I'm gonna open the box another time, maybe I overlooked something.

So I am still puzzled. I booted off of the Suse 10.1 64bit after I saw in the bios, that the CPU is actually 64bit capable (intel's EM64T) but that didn't change a thing.

Thanks!

Martin

On 8/28/06, Ken Jennings wrote:

...

On Monday 28 August 2006 06:59, you wrote:

...

On 8/28/06, Ken Jennings wrote: [...]

...

A: Due to standard PC architecture, a certain amount of memory is reserved for system usage and therefore the actual memory size is less than the stated amount. For example, 4GB of memory size will instead be shown as 3.xxGB memory during system startup. THE MEMORY SIZE WILL BE VARIED according to different chipsets, different VGA card used, DIFFERENT ONBOARD CONTROLLERS like audio and LAN etc, different add on cards used.

You should see a similar message in the manual under "Feature Summary". In the English manual that's section 1-2, page 12.

All that onboard stuff -- lan, Audio, disks, etc. Have to live somewhere in the memory map, so some RAM is "lost" if you have maxed out your RAM.

thank you. This sounds pretty OS independant. How come that another installed distro could actually see all of the 4GB?

It may not actually be OS independent. I understand from some other people it may be possible to do a few kernel tweaks to rescue the memory hiding behind the I/O area provided the motherboard actually supports 64-bit addressing. Basically, the kernal asks the bios to map the hidden RAM to a space above the 4G (32-bit) memory map. From what I'm told, this isn't something Windows can do, so the motherboard docs may simply be stating reality from a Windows-centric point of view. (Though I have no clue if your board can really do this.)

Thanks, Ken Jennings

Jan Engelhardt --

On 8/29/06, stephan beal wrote:

On Tuesday 29 August 2006 06:02, Martin Köbele wrote:

...

The slackware kernel which was previously installed (and saw the 4GB) does not even load on this computer anymore (maybe because it doesn't like suse ;) ).

You can try taking the configuration from that kernel and using it on a Suse-supplied kernel source tree. That might help find the option(s) which cause it to see the full 4GB.

I'm afraid I don't have it. Also, it was a 2.4 kernel :/. Martin