tree 9bf8a09179f60ddddbebceb4df34445eff12de16
parent 6f9aa727433fe7647869c9b64ce2f7b5feac0052
author Olof Johansson <[EMAIL PROTECTED]> Mon, 29 Aug 2005 07:42:10 -0500
committer Paul Mackerras <[EMAIL PROTECTED]> Tue, 30 Aug 2005 13:32:08 +1000

[PATCH] PPC64: Don't try to claim memory from OF at 1GB mark

Some RS64-based machines (p620, F80, others) have problems with firmware
returning 0xdeadbeef instead of failure to allocations that end at the
1GB mark.

We have two options:
1. Detect the undocumented 0xdeadbeef return value and interpret it as
a failure.
2. Avoid allocating that high.

(2) is really the cleaner solution here. 768MB is plenty of room so use
that as the max alloc_top instead of 1GB.

Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>

 arch/ppc64/kernel/prom_init.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/ppc64/kernel/prom_init.c b/arch/ppc64/kernel/prom_init.c
--- a/arch/ppc64/kernel/prom_init.c
+++ b/arch/ppc64/kernel/prom_init.c
@@ -892,7 +892,10 @@ static void __init prom_init_mem(void)
        if ( RELOC(of_platform) == PLATFORM_PSERIES_LPAR )
                RELOC(alloc_top) = RELOC(rmo_top);
-               RELOC(alloc_top) = RELOC(rmo_top) = min(0x40000000ul, 
+               /* Some RS64 machines have buggy firmware where claims up at 1GB
+                * fails. Cap at 768MB as a workaround. Still plenty of room.
+                */
+               RELOC(alloc_top) = RELOC(rmo_top) = min(0x30000000ul, 
        prom_printf("memory layout at init:\n");
        prom_printf("  memory_limit : %x (16 MB aligned)\n", 
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to