Re: [SLE] SuSE 10.1 32bit and 4GB RAM, seen are 3.5GB
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 <ken_jennings@bellsouth.net> 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
hi, could it be a e820 related issue? 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 On 8/29/06, Martin Köbele <mkoebele@gmail.com> wrote:
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 <ken_jennings@bellsouth.net> 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
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 <ken_jennings@bellsouth.net> 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 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. -- ----- stephan@s11n.net http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts
On 8/29/06, stephan beal <stephan@s11n.net> 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
participants (3)
-
Jan Engelhardt -
Martin Köbele -
stephan beal