p620 hangs instantiating rtas at 0x00000000deadbeef

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Feb 12 09:54:02 EST 2005

On Thu, 2005-02-10 at 18:01 -0600, Linas Vepstas wrote:

> Once, a long time ago, it was what a register would hold after the CPU
> was powered on the very first time ... 
> Now, it seems to be an error return value from prom_claim() ... 
> seems to be getting returned by firmware ... they probably
> should have returned a -1, those jokers ... 

Yes, definitely looks like a firmware bug to me. This return value is
just insane.

> Anyway, the firmware seems to be telling us that it cannot
> honour the very first request to claim memory right below
> RMO top.

In a broken way, but yes.

> I might be totally insane but I notice that rmo_top is set to 1GB, and I
> thought 256MB was the top ... so try this, for laughs ... in the routine
> static void __init prom_init_mem(void)
> around line 675 
> RELOC(alloc_top) = RELOC(rmo_top) = min(0x40000000ul, RELOC(ram_top
> change the 4 to a 1 ...
> That is my wild guess.

This is not LPAR right ? In this case, RMO doesn't exist as-is, and I
arbitrarily fixed the limit at 1Gb which, according to everybody I asked
by then, was enough (some RTAS didn't support beeing instanciated about

> I notice that someone re-wrote all of that prom code in the last half-year, 
> I don't know who ...  probably Ben ...  they would be the expert 
> for what's going on in here, not me.  I bow out here.

Well, it would be interesting to understand what's up with the firmware.
The alloc_down() routine is designed to retry at a lower address when
the allocation fails but that mecanism is defeated by the bogus return
value from the firmware.


More information about the Linuxppc64-dev mailing list