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
2Gb).
> 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.
Ben.
More information about the Linuxppc64-dev
mailing list