64-bit OpenSUSE 11.1 reports only 2.9 out of 4GB of RAM

English Install/Boot/Login
1

As the title says… I had bought an Acer Aspire 5735 notebook (GM45/ICH9M), which came without OS and with 4GB of DDR2-667 RAM installed in two SODIMMs.

I’ve installed x86-64 version of OpenSUSE 11.1 (default kernel) on it but the OS reports only 2.9GB!?! And yes, the CPU is 64-bit one… And no, I don’t have “memory hole remapping” nor any other memory related settings in the BIOS. Actually, I don’t have any sensible settings in BIOS whatsoever, besides clock/date and “SATA mode”!!! >:(

Concatenating /proc/cpuinfo shows that CPU is capable of 36-bit physical addressing, and BIOS reports all 4096 MBytes of RAM. :\

I should probably mention that memtest86 also reported ~3GB…

The only thing I can think of is to try whit a BIOS update. Beyond that, I’m clueless. :\

2

Your motherboard may not actually support more than 4GB due to lack of address lines on the board. The kernel cannot give the user more than 3GB of that space and then a bit is lost to various holes. Not much you can do about that.

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Even if you were on a 32-bit version of OpenSUSE your system should
report more RAM than a measly 2.9 GB… this sounds more like a weird
reporting issue between the BIOS and the kernel, though how you’d track
it down… I’m not sure. Tried another distro, or a LiveCD or LiveDVD?

Good luck.

marcus magick wrote:
> As the title says… I had bought an Acer Aspire 5735 notebook
> (GM45/ICH9M), which came without OS and with 4GB of DDR2-667 RAM
> installed in two SODIMMs.
>
> I’ve installed x86-64 version of OpenSUSE 11.1 (default kernel) on it
> but the OS reports only 2.9GB!?! And yes, the CPU is 64-bit one… And
> no, I don’t have “memory hole remapping” nor any other memory related
> settings in the BIOS. Actually, I don’t have any sensible settings in
> BIOS whatsoever, besides clock/date and “SATA mode”!!! >:(
>
> Concatenating /proc/cpuinfo shows that CPU is capable of 36-bit
> physical addressing, and BIOS reports all 4096 MBytes of RAM. :
>
> I should probably mention that memtest86 also reported ~3GB…
>
> The only thing I can think of is to try whit a BIOS update. Beyond
> that, I’m clueless. :
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJflLF3s42bA80+9kRAhLcAJ9ym6xYAmB+ojwWl5sAP/Krbo0RxgCfQ+Xs
0B1+LSbrqQnwyYbSaDHMes4=
=LSLq
-----END PGP SIGNATURE-----

4

Acer unambiguously states that this model supports up to 4GB of RAM, and there are lots of those notebooks (5735) coming with 2GB of RAM which is installed as a single SODIMM. Besides… BIOS does report 4029 MB of system memory and 64 MB of video memory (+ less then a MB reserved for mem hole).:confused:

I’ve just realized that /proc/mtrr shows some rather unusual results:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2040MB), size=1024MB: write-back, count=1
reg02: base=0x10000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbc000000 (3008MB), size=  64MB: uncachable, count=1
reg04: base=0xbbc00000 (3004MB), size=   4MB: uncachable, count=1
reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1

P.S. I’ve also tried passing the ‘mem=4G’ parameter to the kernel, as well as ‘mem=5G’, which had worked for some people, but unfortunately in my case it didn’t do anything.

5

Hi Ab,

Thank you for your reply. I also suspect faulty BIOS. I’ll try newer BIOS version and a 64-bit Vista and report back with the results.

Regards,

Marcus

6

However even if the mobo accepts 4GB of RAM sticks doesn’t mean that all of this RAM is accessible. It also depends on whether there is addressing above 4GB, because RAM in holes have to be remapped above the 4GB address. But I would expect more than 2.9GB available, that does seem a bit low.

7

Did you also cat /proc/meminfo? The number seems a bit low. My Compaq Presario came with 2GB in two SODIMs. I pulled those out and put in 4GB G.Skill. Right now I am seeing 3.84GiB which is about right.

Did you do a full memtest run? Usually this takes several hours, but it is worth it and will help identify potential problems.

8

Acer clearly states in its spec:
DDR2 memory, upgradeable to 4 GB using dual soDIMM modules.

It is ridiculous to state support for 4GB of system memory when in fact only 3GB could be used under any circumstances.

It would be like stating support for analog video output (HD-15) up to 2048x1536@85Hz, while integrating DAC that could do only 1600x1200@60Hz. Law suits would just keep coming…

It also depends on whether there is addressing above 4GB, because RAM in holes have to be remapped above the 4GB address. But I would expect more than 2.9GB available, that does seem a bit low.

How memory hole could be remapped above 4GB addresses when I have only 4GB of RAM? :\ It would fell into a swap space (virtual memory).

Besides… GM45 supports 36-bit physical addressing, and maximum of 8GB of DDR2 667/800, so I don’t see how that could be a problem. :\

9

Yes I did. It says:

MemTotal:      3014544 kB
MemFree:     2526392 kB
Buffers:       14616 kB
...
...
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
DirectMap4k:    143360 kB
DirectMap2k:   2932736 kB

Did you do a full memtest run? Usually this takes several hours, but it is worth it and will help identify potential problems.

The memtest86 detects only ~3GB of RAM, and I don’t see any point in doing such test.

10

I forgot to mention that dmidecode states that “Physical Memory Array” has “Maximum Capacity: 4 GB”. It also identifies two 2GB memory modules in their respective SODIMM slots.

Spooky, a? :slight_smile:

11

Look, here’s how it happens. This is a server with 8GB of memory:

BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 0000000000100000 - 00000000bffc0000 (usable)
BIOS-e820: 00000000bffc0000 - 00000000bffcfc00 (ACPI data)
BIOS-e820: 00000000bffcfc00 - 00000000bffff000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000fec90000 (reserved)
BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 00000001ffffe000 (usable)
BIOS-e820: 00000001ffffe000 - 0000000200000000 (reserved)
BIOS-e820: 0000000200000000 - 0000000240000000 (usable)

With 8GB of memory, normally the addresses will run up to 0x200000000. However notice that some memory is now addressed above 0x200000000 because some addresses are used by non-memory.

But the controller chipsets have to support this. Your notebook may, I’m not saying that it doesn’t. But the point is that there isn’t a one-to-one mapping between addresses seen by the memory sticks and the physical addresses seen by the CPU. It goes through the controller.

12

My Award BIOS on an ASUS A8N-SLI board had a parameter “S/W DRAM over 4G remapping”. Setting this to Enable allowed 3.9GByte out of 4GByte to be recognized.
HTH

13

Please don’t get this the wrong way, but I’m an IT engineer, and I know quite a lot about translation lookaside buffers, virtual addressing and memory management in general… :slight_smile:

I was just saying that this must be some kind of screw-up between BIOS-(MTRR)-Kernel.

14

Believe it or not, I have only “SATA Mode” (IDE/AHCI), Clock/Date and Password setup in my BIOS! >:(

15

Ok, but how about showing us the E820 lines from the boot log, like the ones I’ve posted. That will tell us if the holes are getting remapped at least.

16

It sure seems that something is wrong with the BIOS.

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
 BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000bb6a1000 (usable)
 BIOS-e820: 00000000bb6a1000 - 00000000bb6a7000 (reserved)
 BIOS-e820: 00000000bb6a7000 - 00000000bb7bc000 (usable)
 BIOS-e820: 00000000bb7bc000 - 00000000bb80f000 (reserved)
 BIOS-e820: 00000000bb80f000 - 00000000bb908000 (usable)
 BIOS-e820: 00000000bb908000 - 00000000bbb0f000 (reserved)
 BIOS-e820: 00000000bbb0f000 - 00000000bbb18000 (usable)
 BIOS-e820: 00000000bbb18000 - 00000000bbb1f000 (reserved)
 BIOS-e820: 00000000bbb1f000 - 00000000bbb64000 (usable)
 BIOS-e820: 00000000bbb64000 - 00000000bbb9f000 (ACPI NVS)
 BIOS-e820: 00000000bbb9f000 - 00000000bbbe2000 (usable)
 BIOS-e820: 00000000bbbe2000 - 00000000bbbff000 (ACPI data)
 BIOS-e820: 00000000bbbff000 - 00000000bbc00000 (usable)
 BIOS-e820: 00000000bbc00000 - 00000000bbe00000 (reserved)
 BIOS-e820: 00000000bc000000 - 00000000c0000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
 BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
 BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
DMI present.
Phoenix BIOS detected: BIOS may corrupt low RAM, working it around.
last_pfn = 0xbbc00 max_arch_pfn = 0x3ffffffff
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
init_memory_mapping
 0000000000 - 00bbc00000 page 2M
kernel direct mapping tables up to bbc00000 @ 10000-14000
last_map_addr: bbc00000 end: bbc00000

Could someone please check my /proc/mtrr, that I’ve posted earlier, because something doesn’t adds up.

17

Yes, it’s odd that the usable memory ends at bbc00000. This is very fascinating, er I mean, very puzzling. Sorry I don’t have any ideas, I’m just as curious as the next person to see what it turns out to be.

18

Does your laptop have dedicated video memory or is it sharing from your system ram?

If sharing, look in the bios for an option that specifies how much ram to use as video memory.

EDIT: Just read a previous post.

19

> I’ve just realized that /proc/mtrr shows some rather unusual results:
>
> Code:
> --------------------
> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2040MB), size=1024MB: write-back, count=1
> reg02: base=0x10000000 (4096MB), size=1024MB: write-back, count=1
> reg03: base=0xbc000000 (3008MB), size= 64MB: uncachable, count=1
> reg04: base=0xbbc00000 (3004MB), size= 4MB: uncachable, count=1
> reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
>
> --------------------

Hmm, assuming you typed this in by hand and just omitted one zero
from the hex base address at reg02, that doesn’t look too bad to me.
3 GB mapped from address 0 by reg00 and reg01, and the remaining
GB remapped above the 4 GB limit by reg02.

But I admit I don’t know terribly much about MTRRs; perhaps it’s a
problem that the base addresses aren’t in ascending order. Is that
legal?

HTH
T.

–
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

20

Hi Tilman,

Thanks for reply. Yes, you are right… I did typed that in by hand, and yes… there should be one more zero. :shame: