Re: memory management issue (Re: another regression on Efika)

[Hollis Blanchard]

On 7/24/07, Robert Millan <address@hidden> wrote:
> On Sat, Jul 14, 2007 at 12:08:30AM +0200, Robert Millan wrote:
> > On Tue, Jul 10, 2007 at 03:32:30PM -0500, Hollis Blanchard wrote:
> > > > > In short, whatever is causing these crashes is not only an Efika issue.
> > > > > I suspect Apple, or Apple powerbooks at least, are also affected. I got
> > > > > Sjoerd to try this on his powerbook, and he confirms this fixes for him.
> > > > > Paul also tried, with the same results. Not all the powerbooks are the
> > > > > very same model, there are different model revisions involved.
> > > >
> > > > The error Jordi was seeing before reverting your commits was very similar 
> to
> > > > what I get on my Efika (something like "claim failed").
> > > >
> > > > Hollis, do you still think this is a firmware bug?
> > >
> > > Could somebody please debug it and report back if it is really a GRUB
> > > issue? It could be as simple as adjusting the link address, or it could
> > > mean instrumenting grub_available_iterate() and checking that output
> > > with the contents of /memory/available.
> >
> > It turns out that grub_claim_heap() was asked to claim a region that starts
> > after the heap limit.  The start address (0x19111e4) is correctly obtained
> > from /memory/available.
> >
> > Should heap limit be increased?
>
> The attached patch fixes the problem for Efika, although I'm not 1:1 sure of
> its correctness.
>
> It seems to me that heaplimit is meant to be used as a relative offset, not
> as an absolute memory address.  This makes the current code fail when the
> start address in /memory/available is higher than heaplimit, and I don't
> think there's anything that can grant us this won't happen.  From this POV,
> it's clear that moving from relative to absolute address is wrong.
>
> OTOH, your commit indicates (as per variable names, etc) that this change
> was done intentionally; so I have to assume there would be a reason for that.
> Please can you clarify?
>
> Btw, the attached patch doesn't fix the problem for Jordi (Mac).  Maybe
> we're talking about two separate bugs after all.

I was indeed trying to make it absolute. GRUB is linked at 0x10000, or
64KB. Add in all the modules and you still are only using a couple
hundred KB.

I don't remember *why* I was trying to make it absolute; I'm sure it
was to fix a problem (rather than I was bored). If we could get away
from this anachronistic Changelog crap, the commit message would have
told us exactly what we need to know.

I *think* it was because we have a relocation problem with OSes that
are linked at 4MB, which is the case with Xen (and I believe yaboot).
If GRUB is using that memory, we simply can't load anything there.

I think we can add some somewhat-special-case logic that says if there
is nothing available below HEAP_LIMIT, claim something beginning as
low as we can. That reduces functionality on such platforms (as
described above), but there's little we can do about that unless
firmware is fixed.

My big question is this: why is Efika firmware saying that 0x19111e4
(around 25MB) is the first available address?

BTW, does Jordi have any details on this Mac problem?

-Hollis