bigmem kernel installed but still only 3 gigs of ram? (Debian)
 

Hello people,

I'm using Debian Squeeze/Sid and I recently installed a 2 gb ram stick in my pc, so now I have 2 modules of 2 gb's each one. I started the pc after installing the new stick, but the amount detected by debian was 3231 mb's, so I installed all the *-bigmem kernels (for 2.6.32-5-686), restarted, but still the only available memory when executing "free -m" is 3231 mb's. I Know about the 32 bit limitation when it comes to the maximum amount of ram the OS can use, but from the things I've read on the net, the bigmem kernel should solve the issue? (I'm not very keen of installing a 64 bit kernel or OS, since some programs on wine don't work fine on 64 bit for me :().

Some information that might be useful: the BIOS detects al the 4 gigs (4096 mb), but windows xp (32 bit) only detects 3 point something (don't remember exactly how much, but it's pretty much the same amount as debian). And something else that might be relevant: the 2 modules aren't the same speed; one is 667 mhz and the other one is 800 mhz, but I set the frequency for both of them to 800 mhz in the BIOS. Also, the graphic card is a nvidia 7300 with 512 mb of ram, so I guess it shouldn't be using the motherboard ram.


Here are my specs:
Processor: Core 2 Duo (model 7500 @ 2.93 ghz)
Graphic card: Nvidia 7300 GS (with 512 mb of ram)
Motherboard: asrock g31m-s R2.0

I know this question must have been asked here lots of times, but most people on the net report the issue is solved with a bigmem kernel, so I thought I'd better ask :). (Anyway, sorry if this specific question has been asked before).

Greetings, and thanks in advance!

From a terminal do:
and read this: http://www.linuxatemyram.com/ :)

EDIT: If this isn't the issue, then you need to do:
to see if you are actually running the bigmem kernel.

Hi, thanks for your answer,

free -m gives me this:

uname -a, gives me this:

"lshw -C memory", gives this:

And "cat /proc/meminfo" gives me this:

So the memory should be detected properly, but still it isn't :-/. lshw shows 4gb's, but "free -m" says the total amount is 3231 mb (prety much the same amount "cat /proc/meminfo" shows). Could it be some setting in the BIOS? (I've checked it many times, but everything seems to be fine).

Regards and thanks again!

For some reason I think there is also an issue with the board chipset too. I think it was on an intel site that has what was needed.

Likely you have a BIOS or motherboard issue, so a 64 bit kernel wouldn't help.

Post your "BIOS provided memory map" to confirm whether the problem is BIOS/Motherboard (vs. kernel).
See some discussion of that starting here:
http://www.linuxquestions.org/questi...2/#post3150011

The fact that the BIOS reports the ram to the user and that lshw and other dmi decode based tools see the full 4GB means far less than you'd expect. It does not mean that the BIOS does (or even can) enable the ram for use by the OS.

Thanks a lot, johnsfine! I checked the link you posted, and indeed, I had to enable the memory remap feature in the BIOS. Now "free -m" shows all the 4 gbs of ram (as well as /proc/meminfo) :D. Windows shows only 3 gigs, but I guess this is normal on windows 32 bit?

I don't think this is needed anymore, but just in case, here's the output dmesg (after enabling the memory remap feature):

And this is the relevant part of /var/log/dmesg.0 (which, I guess, was written before enabling the memory remap feature):

But, what all these numbers mean? Is the memory problem some defect in the BIOS, or the motherboard? Also, is it normal for windows xp 32 bit to read up to 3 gbs only?

The numbers are ranges of address space in hex along with the status of each range. "usable" means the range has memory the BIOS has enabled for OS use. Anything else is something other than memory usable by the OS.

I don't know why anyone would want to turn off the "memory remap" feature (name varies from one BIOS to another), but I wouldn't go so far as to say that giving you the ability to turn it off is a defect. Maybe it defaulted to off. That is nearly bad enough to call a "defect", but it is pretty common.

A 32 bit kernel without PAE can only use 4GB of address space, which many people (including those who write motherboard specs) confuse with 4GB of "memory".

4GB of address space is only enough for 3 and a fraction GB of memory.

The feature you turned on in the BIOS enables the ram the part of the first 4GB of ram that is outside the first 4GB of address space. Some OS's can use that ram. Others can't. But even if the OS can't use it, having the BIOS enable it won't hurt any OS that is current or a few generations obsolete (might hurt some super obsolete early protected mode OS).

Yes. XP 32 has PAE support, but does some kind of license check to decide whether to enable ram outside 4GB of address space. For normal licenses it disables that ram. Before 64 bit Windows, that license check let them charge more for the rare feature of supporting over 3.xGB of ram. But 64 bit Windows made that more costly license for 32 bit Windows obsolete. Also some device drivers aren't compatible with PAE's extended ram support. The power of open source quickly resolved all the issues in non PAE compatible drivers for Linux long long ago. But in Windows, such drivers persisted. So I guess the license check also serves to reduce complaints about incompatible drivers.

You can use ram outside 4GB of address space only if the motherboard/chipset support it (most do, a few don't) and the BIOS enables it and the OS kernel allows it (64 bit and Linux 32 bit PAE and special licenses of 32 bit Windows all allow it. Other 32 bit kernels don't).

I get it, thanks for the comprehensive explanation, and thanks again for your help. Thanks to brucehinrichs and jefro too :).

Regards.

I know this is solved but just to add in some data.

From MS site. (don't boo me) Similar data on an Intel pages somewher.

This behavior is the expected result of certain hardware and software factors.

Various devices in a typical computer require memory-mapped access. This is known as memory-mapped I/O (MMIO). For the MMIO space to be available to 32-bit operating systems, the MMIO space must reside within the first 4 GB of address space.

For example, if you have a video card that has 256 MB of onboard memory, that memory must be mapped within the first 4 GB of address space. If 4 GB of system memory is already installed, part of that address space must be reserved by the graphics memory mapping. Graphics memory mapping overwrites a part of the system memory. These conditions reduce the total amount of system memory that is available to the operating system.

The reduction in available system memory depends on the devices that are installed in the computer. However, to avoid potential driver compatibility issues, the 32-bit versions of Windows Vista limit the total available memory to 3.12 GB. See the "More information" section for information about potential driver compatibility issues.

If a computer has many installed devices, the available memory may be reduced to 3 GB or less. However, the maximum memory available in 32-bit versions of Windows Vista is typically 3.12 GB.
Back to the top
WORKAROUND
For Windows Vista to use all 4 GB of memory on a computer that has 4 GB of memor...
For Windows Vista to use all 4 GB of memory on a computer that has 4 GB of memory installed, the computer must meet the following requirements:

* The chipset must support at least 8 GB of address space. Chipsets that have this capability include the following:
o Intel 975X
o Intel P965
o Intel 955X on Socket 775
o Chipsets that support AMD processors that use socket F, socket 940, socket 939, or socket AM2. These chipsets include any AMD socket and CPU combination in which the memory controller resides in the CPU.
* The CPU must support the x64 instruction set. The AMD64 CPU and the Intel EM64T CPU support this instruction set.
* The BIOS must support the memory remapping feature. The memory remapping feature allows for the segment of system memory that was previously overwritten by the Peripheral Component Interconnect (PCI) configuration space to be remapped above the 4 GB address line. This feature must be enabled in the BIOS configuration utility on the computer. View your computer product documentation for instructions that explain how to enable this feature. Many consumer-oriented computers may not support the memory remapping feature. No standard terminology is used in documentation or in BIOS configuration utilities for this feature. Therefore, you may have to read the descriptions of the various BIOS configuration settings that are available to determine whether any of the settings enable the memory remapping feature.
* An x64 (64-bit) version of Windows Vista must be used.

Contact the computer vendor to determine whether your computer meets these requirements.

Note When the physical RAM that is installed on a computer equals the address space that is supported by the chipset, the total system memory that is available to the operating system is always less than the physical RAM that is installed. For example, consider a computer that has an Intel 975X chipset that supports 8 GB of address space. If you install 8 GB of RAM, the system memory that is available to the operating system will be reduced by the PCI configuration requirements. In this scenario, PCI configuration requirements reduce the memory that is available to the operating system by an amount that is between approximately 200 MB and approximately 1 GB. The reduction depends on the configuration.

http://support.microsoft.com/kb/929605

Very good explanation, thanks for sharing!

Same problem, no BIOS memory remapping available. What to do?
 

Hi

I understand that this issue is solved by enabling memory remapping in the BIOS configuration. But what if one can't go that way?

I have the same problem with my old Acer Aspire 9423WSMi (Aspire 9420 series). I upgraded to the latest BIOS (1.24 15/11/2007) but it still only sees 3Gb.

I haven't been able to find an option on the BIOS that will allow me to enable memory remapping. Has anyone solved it without it?

I post some info on my system, Debian Testing, in case it might be helpful:

$ uname -a
Linux xxxxxxxx 2.6.32-5-686-bigmem #1 SMP Tue Jun 1 05:38:08 UTC 2010 i686 GNU/Linux

$ free -m
total used free shared buffers cached
Mem: 3040 1099 1941 0 90 504
-/+ buffers/cache: 504 2535
Swap: 1023 0 1023

$ sudo lshw -C memory
*-firmware
description: BIOS
vendor: Phoenix Technologies LTD
physical id: 0
version: V1.24 (11/15/2007)
size: 105KiB
capacity: 960KiB
capabilities: isa pci pcmcia pnp apm upgrade shadowing escd cdboot acpi usb agp biosbootspecification
*-cache:0
description: L1 cache
physical id: 5
slot: L1 Cache
size: 16KiB
capacity: 16KiB
capabilities: asynchronous internal write-back
*-cache:1
description: L2 cache
physical id: 6
slot: L2 Cache
size: 2MiB
capabilities: burst external write-back
*-memory
description: System Memory
physical id: 10
slot: System board or motherboard
size: 4GiB
*-bank:0
description: SODIMM DDR2 Synchronous
physical id: 0
slot: M1
size: 2GiB
width: 32 bits
*-bank:1
description: SODIMM DDR2 Synchronous
physical id: 1
slot: M2
size: 2GiB
width: 32 bits

$ cat /proc/meminfo
MemTotal: 3113448 kB
MemFree: 1982564 kB
Buffers: 92816 kB
Cached: 516192 kB
SwapCached: 0 kB
Active: 639016 kB
Inactive: 390408 kB
Active(anon): 426740 kB
Inactive(anon): 16 kB
Active(file): 212276 kB
Inactive(file): 390392 kB
Unevictable: 16 kB
Mlocked: 16 kB
HighTotal: 2234952 kB
HighFree: 1269140 kB
LowTotal: 878496 kB
LowFree: 713424 kB
SwapTotal: 1048568 kB
SwapFree: 1048568 kB
Dirty: 364 kB
Writeback: 0 kB
AnonPages: 420432 kB
Mapped: 94884 kB
Shmem: 6340 kB
Slab: 49408 kB
SReclaimable: 38192 kB
SUnreclaim: 11216 kB
KernelStack: 2248 kB
PageTables: 5480 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2605292 kB
Committed_AS: 1005652 kB
VmallocTotal: 122880 kB
VmallocUsed: 89228 kB
VmallocChunk: 6720 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 28664 kB
DirectMap2M: 880640 kB

$ sudo dmesg | less
... skip ...

[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bfe90000 (usable)
[ 0.000000] BIOS-e820: 00000000bfe90000 - 00000000bff00000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bff00000 - 00000000c0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[ 0.000000] ACPI: Shall use APIC/MADT table 2
[ 0.000000] DMI present.
[ 0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] last_pfn = 0xbfe90 max_arch_pfn = 0x1000000

Regards and thanks in advance!

/Jordi

There is no solution in Linux unless you solve the underlying problem in the BIOS.

For some motherboards, there is just no solution (nothing the BIOS could do to enable all the ram).

But where there is a BIOS solution, it might be named strangely and or be fairly well hidden. For example there might be a default of hiding many BIOS options with a choice somewhere of "advanced" or something similar that must be turned on to unhide them.

Is there an online PDF file from the motherboard manufacturer describing the BIOS menu (for most motherboards there is)? If so, is it fairly close to an accurate description of the actual BIOS menu? If so, post a URL. I might spot the right menu option in the PDF even if it isn't obvious in the BIOS itself.

While your checking that, also see if there is a newer version of BIOS available for your motherboard. A newer version may include more features, such as remapping.

Hi

Thanks for your replies. I have the latest official BIOS for my computer, and it does not have any options related to memory management. I've tried some hacked BIOS I found on http://forum.notebookreview.com/acer...d-request.html, but didn't help either. Just now I've asked the guys at that forum whether it would be possible to get a hacked BIOS with the needed option available.

I'll try to find out the make and model of my motherboard (I'm afraid I'll have to physically open my laptop) and see if I can find some documentation on it.

I'll keep you informed.

Thanks

Hi all

At the Noteboot Review forum I was told that this motherboard's BIOS might not have such an option. I was also told to try a 64-bit kernel, which I did, to no avail.

I started then looking for information on my motherboard, and that's how I found out that, apparently, the problem appears to be the chipset on my motherboard (Mobile Intel 945PM Express Chipset) which, according to this report (http://www.tomsguide.com/us/hp-dv100...iew-679-6.html), is not "validated" to support all 4Gb @ 667 MHz, but should support all 4 Gb @ 533 MHz. The same is reported on the specs table in this report (http://www.xbitlabs.com/articles/mob...no-duo_7.html#) I must say I'm a bit skeptical that it will work, but I want to try a slower memory anyway.

I sent back my 2x2Gb@667MHz and, the vendor said, my 2x2Gb@533MHz will probably ship tomorrow.

I'll come back with the result. Whish me luck :-)

Thanks