Bug 124388 - Bootprompt's mem=? seems to have a 1024 mb limit
Bootprompt's mem=? seems to have a 1024 mb limit
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: Jason Baron
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-26 05:17 EDT by Robert Scheck
Modified: 2013-03-06 00:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-06 07:08:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2004-05-26 05:17:23 EDT
Description of problem:
"linux mem=2000m" or "linux mem=2g" at the boot prompt don't work:

--- snipp ---
[root@tux.ia64 root]# free
             total       used       free     shared    buffers     cached
Mem:       1005968     149648     856320          0      22592      50720
-/+ buffers/cache:      76336     929632
Swap:      2040208          0    2040208
[root@tux.ia64 root]#
--- snapp ---

But the box has 4 GB RAM, here's the proof:

--- snipp ---
[root@tux.ia64 root]# free
             total       used       free     shared    buffers     cached
Mem:       4125200     203584    3921616          0      22480      50592
-/+ buffers/cache:     130512    3994688
Swap:      2040208          0    2040208
[root@tux.ia64 root]#
--- snapp ---

The limit seems to be 1024, because "mem=128m" "mem=768m" up to 1024
work.

Version-Release number of selected component (if applicable):
kernel-2.4.21-9.EL and newer
elilo-3.4-1.3 and newer

How reproducible & Steps to Reproduce:
Every time, see above.
  
Actual results:
Now, I've got to install and uninstall after each benchmark run the 
(un)needed physical memory at the box itself for the next benchmark 
test...hopefully it soon gets solved ;-)

Expected results:
Working mem=? up to the current maximal supported memory size of the
kernel.

Additional info:
I selected the component "kernel" at current but maybe that's wrong.
Comment 1 Suzanne Hillman 2004-05-26 10:21:26 EDT
Does this happen on all of your ia64 machines with appropriate amounts
of memory, or is it specific to a few machines?
Comment 2 Jason Baron 2004-05-26 11:51:32 EDT
mem= acts more like a maximum address rather than a memory counter in
ia64 2.4. Thus when you set it to 2G, and if there is a memory hole
b/w 1G-2G, then you wind up with only one GIG. we could look at the
memory map and figure out how to set it, but if you want 2G, i suspect
booting with mem=3G should work. 

This is fixed already in 2.6 ia64.
Comment 3 Robert Scheck 2004-05-27 09:17:41 EDT
Suzanne, I'm able to reproduce that strange behaviour some of the HP 
ia64 server products (so I only tested a few ones). The first results 
I posted (and which caused me to open this bug) were from a HP 
Integrity rx1600 Server.

I'm sorry, Jason, mem=3G or mem=3000m don't work at this rx1600 
server, I've always maximal 1 GB. There is no empty memory slot in 
the box.

Suzanne, you requested tests at other ia64 servers, so here are my 
testing results from a HP Integrity rx4640 Server, but I'm also able 
to reproduce the same (more or less) bad result at a HP Integrity 
rx2600 Server:

This box has 16 GB RAM for example:

--- snipp ---
[root@rx4640 root]# free
             total       used       free     shared    buffers     cached
Mem:      16617168    1812032   14805136          0     196160     505088
-/+ buffers/cache:    1110784   15506384
Swap:       409568          0     409568
[root@rx4640 root]# 
--- snapp ---

"linux mem=1000m" or "linux mem=1g" works (as usual):

--- snipp ---
[root@rx4640 root]# free
             total       used       free     shared    buffers     cached
Mem:        983104     164304     818800          0       9056      61856
-/+ buffers/cache:      93392     889712
Swap:       409568          0     409568
[root@rx4640 root]#
--- snapp ---

"linux mem=2000m" or "linux mem=2g" doesn't work:

--- snipp ---
[root@rx4640 root]# free
             total       used       free     shared    buffers     cached
Mem:       1001040     177440     823600          0       9360      63536
-/+ buffers/cache:     104544     896496
Swap:       409568          0     409568
[root@rx4640 root]#
--- snapp ---

"linux mem=3000m" or "linux mem=3g" doesn't work:

--- snipp ---
[root@rx4640 root]# free
             total       used       free     shared    buffers     cached
Mem:       1001040     165552     835488          0       9264      63232
-/+ buffers/cache:      93056     907984
Swap:       409568          0     409568
[root@rx4640 root]#
--- snapp ---

"linux mem=10g" brings up 7 GB, that would match with your theory
from comment #2, but what do you mean exactly with "memory hole"? 
There are no empty slots in the box up to the 16 GB, so the memory 
range should be without any hole b/w 0-16 GB - and the rx1600 server 
even hasn't a empty slot...

--- snipp ---
[root@rx4640 root]# free
             total       used       free     shared    buffers     cached
Mem:       7233072     265392    6967680          0       9104      61888
-/+ buffers/cache:     194400    7038672
Swap:       409568          0     409568
[root@rx4640 root]#
--- snapp ---

Sorry, we can't use here a totally unsupported and development 2.6 
ia64 kernel at a supported RHEL3 for offical benchmark tests that 
have to be correct for us - and our customers.

And if there is a fix possible for kernel 2.4 ia64 we would be very 
very happy to get it as an update, it is still enough for us at 
current to limit the maximum address gigabyte-exactly than megabyte-
exactly.
Comment 4 Jason Baron 2004-06-01 11:10:09 EDT
in terms of the 'memory holes' that i was mentioning, it has nothing
to do with memory missing from slots. The ia64 architecture can lave
'holes' in physical memory for things like memory mapped I/O, that is
used to talk with peripherals. Thus, the setting of 'mem=' should be
able to get what you want, but the exact value is maching dependent.
Have you found a value that works for you?
Comment 5 Robert Scheck 2004-06-03 10:11:50 EDT
No, sorry Jason, we didn't find values working for us...
Comment 6 Jason Baron 2004-06-03 17:36:48 EDT
i think we have an rx4640 here that i can look at and try and find the
correct values.
Comment 7 Robert Scheck 2005-02-06 07:08:31 EST
At least 2.4.21-27.EL works for me at RHEL3 for this problem; RHEL4 
works also.

Note You need to log in before you can comment on or make changes to this bug.