Additional memory not detected properly

michaelsr · 05-10-2008, 04:39 PM

I have just upgraded my machine from 2Gb (4 x 500Mb DIMMs) to 4Gb (4 x 1Gb DIMMs). Originally I had no problem detecting the 2Gb but now Linux can only see 2.7Gb!?! The BIOS reports the full 4Gb and goes to post without any errors.

My configuration is as follows:
FC7 x86_64 (see below for more detail)
System: Tyan Thunder K8WE motherboard with 2 x AMD Opteron 280
Memory: Corsair 1Gb PC3200 EC Reg (CM72SD1024RLP-3200/S)
Other info available if required.

Output from uname -a (edited):

Code:

Linux xxxxxxx.com 2.6.23.15-80.fc7 #1 SMP Sun Feb 10 16:52:18 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

Output from /proc/meminfo:

Code:

MemTotal:      2837520 kB
MemFree:       1389392 kB
Buffers:         43500 kB
Cached:         774520 kB
SwapCached:          0 kB
Active:         764012 kB
Inactive:       573904 kB
SwapTotal:     2031608 kB
SwapFree:      2031608 kB
Dirty:              60 kB
Writeback:           0 kB
AnonPages:      519980 kB
Mapped:          85360 kB
Slab:            43304 kB
SReclaimable:    17420 kB
SUnreclaim:      25884 kB
PageTables:      29648 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   3450368 kB
Committed_AS:  1290036 kB
VmallocTotal: 34359738367 kB
VmallocUsed:     27496 kB
VmallocChunk: 34359710203 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

Thanks,

Michael.

hal8000b · 05-10-2008, 04:55 PM

I dont use Fedora, but it sounds like the Fedora Kernel does not have high memory support. You will have to either download an alternate kernel or compile your own with the highmem flag set to enable.
Heres a link that shows where the highmem option is under processor features:

http://www.togaware.com/linux/surviv..._Compiles.html

Hope that helps

jailbait · 05-10-2008, 05:06 PM

You need to have a kernel compiled for large memory. One of these kernel parameters needs to be set in your kernel compile:

CONFIG_HIGHMEM4G=y
CONFIG_HIGHMEM64G=y

Check your Fedora repository to see if they have a precompiled kernel that is both 64bit and HIGHMEM.

-----------------------
Steve Stites

michaelsr · 05-10-2008, 05:16 PM

Thanks but this is a 64bit kernel and, as I understand it, even with 32 bit kernels, the problems with additional memory only happen beyond 4Gb. I am certain that FC7 supports more than 2.7Gb (unless someone out there knows netter!).

Best wishes,

Michael.

syg00 · 05-10-2008, 05:25 PM

The highmem setting is not relevant for 64-bit.

Does dmesg have anything to say on the subject ?.

Electro · 05-10-2008, 06:22 PM

I suggest see if 4 GB of RAM is found by the kernel when using HIGHMEM support on a 64-bit kernel. I think using HIGMEM support will provide better compatibility with 32-bit programs.

I suggest viewing /var/log/messages to get a more thorough look what the kernel is doing upon boot up. The utility dmesg holds very little amount of information that can be missed.

onebuck · 05-11-2008, 12:10 PM

Hi,

Quote:

Originally Posted by Electro

I suggest see if 4 GB of RAM is found by the kernel when using HIGHMEM support on a 64-bit kernel. I think using HIGMEM support will provide better compatibility with 32-bit programs.

I suggest viewing /var/log/messages to get a more thorough look what the kernel is doing upon boot up. The utility dmesg holds very little amount of information that can be missed.

How would 'CONFIG_HIGHMEM4G=y' set affect compatibility with a 32 bit computer program on a 64 bit system?

If I want to know the HIGHMEM support on my Slackware® 12.1 system then a simple 'cat /boot/config-huge-smp-2.6.24.5-smp |grep -i HIGHMEM' would give me;

Quote:

:~# cat /boot/config-huge-smp-2.6.24.5-smp |grep -i HIGHMEM
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y

You can check the other configs for the installed kernels. You could simply look at 'cat /proc/meminfo' to see what memory has been seen by the current kernel.

johnsfine · 05-11-2008, 12:34 PM

Quote:

Originally Posted by onebuck

How would 'CONFIG_HIGHMEM4G=y' set affect compatibility with a 32 bit computer program on a 64 bit system?

It doesn't. Electro was incorrect. (Maybe that's what you meant by asking the question).

I assume (haven't checked) that if you select 64 bit, there isn't even a question for CONFIG_HIGHMEM4G in the config process. There is nothing in the 64 bit kernel build process for that option to even control.

Quote:

Originally Posted by michaelsr

even with 32 bit kernels, the problems with additional memory only happen beyond 4Gb. I am certain that FC7 supports more than 2.7Gb (unless someone out there knows netter!).

The BIOS (not the kernel) decides how much of the first 4GB is strangely remapped. Usually that is about .75GB. 1.3GB sounds like more than the BIOS would remap, but it is hard to be sure.

A 32bit kernel needs CONFIG_HIGHMEM4G=y to have any chance to get at the remapped memory. A 64bit kernel has no such restriction. But either needs some cooperation with the BIOS to understand what memory is available. That cooperation sometimes goes wrong and that might be your issue.

johnsfine · 05-11-2008, 12:45 PM

On my own Linux system, there are several easy ways to look at the memory info the BIOS passed to the Linux Kernel. The easiest is

Code:

dmesg | less

Near the top of that is the following table.

Code:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000bbee0000 (usable)
 BIOS-e820: 00000000bbee0000 - 00000000bbee3000 (ACPI NVS)
 BIOS-e820: 00000000bbee3000 - 00000000bbef0000 (ACPI data)
 BIOS-e820: 00000000bbef0000 - 00000000bbf00000 (reserved)
 BIOS-e820: 00000000bc000000 - 00000000c0000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f2000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000240000000 (usable)

If you can find the similar table in your system and if that isn't enough to answer your whole question, paste it into this thread and I'll explain what it all means.

In a couple other threads, I was surprised/disappointed when I told people to look in the same place for that table that I found it, but in their system it wasn't present. Maybe some other expert here can tell you how to get that table if dmesg | less doesn't give it to you.

michaelsr · 05-11-2008, 01:19 PM

Thanks, here's the output from dmesg | less. I am having a trawl through but am not quite clear what is what and what I can/should change.

Code:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000094000 (usable)
 BIOS-e820: 0000000000094000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000c2000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000aff20000 (usable)
 BIOS-e820: 00000000aff20000 - 00000000aff2d000 (ACPI data)
 BIOS-e820: 00000000aff2d000 - 00000000aff80000 (ACPI NVS)
 BIOS-e820: 00000000aff80000 - 00000000b0000000 (reserved)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)

(I am aware that aff80000 is 2.7 Gb)

Thanks,

Michael

johnsfine · 05-11-2008, 01:39 PM

The BIOS is only reporting 2.7 GB.

I don't know whether it is failing to remap the rest or just failing to report that it has remapped the rest.

2.7GB still seems like a very strange place for the BIOS to stop.

If it has remapped the rest, but failed to report it, there are kernel boot time options to make the kernel see extra memory that the BIOS hasn't reported. I don't know the details (never needed them myself) but I have seen them discussed in other threads.

The remapped memory (if it exists) would be somewhere (probably immediately) above the 4GB point. I think you need to give a boot time option telling Linux it has more than 4GB to get it to look there and find that missing 1.3GB.

If the BIOS hasn't remapped it at all, I don't know if there is anything you could do about that in Linux.

Go carefully through all the BIOS settings and see if there is any BIOS option that looks like it might have influence on how the BIOS configure memmory addresses and/or how it reports memory to the OS.

michaelsr · 05-11-2008, 01:46 PM

Eureka! I needed to turn on memory hole remapping (now set to hardware). The system is now showing 3.9Gb - I presume that that is as good as it's going to get.

I just missed the option in the depth of my BIOS menus.

Thanks to everyone for your help.

Michael.

H_TeXMeX_H · 05-11-2008, 01:47 PM

EDIT:
Good to see it worked.

Here's what I was gonna post, not sure it would have helped.

You can try 'cat /proc/iomem', that'll give you some info, maybe not the one you need.

Here's some info on what it is:
http://www.redhat.com/docs/manuals/e...roc-iomem.html

onebuck · 05-11-2008, 02:22 PM

Hi,

Quote:

Originally Posted by johnsfine

It doesn't. Electro was incorrect. (Maybe that's what you meant by asking the question).

I wanted a definition as to how that could be from him. I'm sure that electro would answer but the statement indeed is wrong but maybe he just misstated. I was being sarcastic with the question.

Quote:

Originally Posted by johnsfine

I assume (haven't checked) that if you select 64 bit, there isn't even a question for CONFIG_HIGHMEM4G in the config process. There is nothing in the 64 bit kernel build process for that option to even control.

Well for Slackware® 12.1;

Quote:

cat /boot/config-generic-smp-2.6.24.5-smp |grep -i highmem
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y

I have to bring up the 64 system to check that out.

syg00 · 05-11-2008, 05:08 PM

As I said, HIGHMEM isn't relevant for 64-bit - once you select that in a current config some (including HIGHMEM) irrelevant options disappear.
Hopefully the merge of the 32bit and 64bit Kconfigs will be complete soon.