rtas instantiation when commandline contains mem

rtas instantiation when commandline contains mem

[Benjamin Krill]

Hi,

the rtas instantiation (prom_init.c) doesn't work correctly if the
kernel parameter "mem=" is used. The current code doesn't evaluate
the kernel parameter which causes the issue that alloc_down
allocates somewhere in the "real" memory space. So it can
happen that the allocation space is above "mem=".

Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
evaluation of "mem=".

cheers
 ben

Re: rtas instantiation when commandline contains mem

[Benjamin Herrenschmidt]

On Thu, 2009-07-16 at 15:12 +0200, Benjamin Krill wrote:
> Hi,
> 
> the rtas instantiation (prom_init.c) doesn't work correctly if the
> kernel parameter "mem=" is used. The current code doesn't evaluate
> the kernel parameter which causes the issue that alloc_down
> allocates somewhere in the "real" memory space. So it can
> happen that the allocation space is above "mem=".
> 
> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
> evaluation of "mem=".

Ah yes, we don't constraint prom_init.c to mem=, only the kernel

Cheers,
Ben.

Re: rtas instantiation when commandline contains mem

[Benjamin Krill]

>> the rtas instantiation (prom_init.c) doesn't work correctly if the
>> kernel parameter "mem=" is used. The current code doesn't evaluate
>> the kernel parameter which causes the issue that alloc_down
>> allocates somewhere in the "real" memory space. So it can
>> happen that the allocation space is above "mem=".
>> 
>> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
>> evaluation of "mem=".
>
>Ah yes, we don't constraint prom_init.c to mem=, only the kernel

Is that with intent? Or should I provide a patch to include it again?

cheers
 ben
>
>

Re: rtas instantiation when commandline contains mem

[Benjamin Herrenschmidt]

On Fri, 2009-07-17 at 08:36 +0200, Benjamin Krill wrote:
> >> the rtas instantiation (prom_init.c) doesn't work correctly if the
> >> kernel parameter "mem=" is used. The current code doesn't evaluate
> >> the kernel parameter which causes the issue that alloc_down
> >> allocates somewhere in the "real" memory space. So it can
> >> happen that the allocation space is above "mem=".
> >> 
> >> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
> >> evaluation of "mem=".
> >
> >Ah yes, we don't constraint prom_init.c to mem=, only the kernel
> 
> Is that with intent? Or should I provide a patch to include it again?

Well I suppose it makes sense to include it again, not sure about that,
there's potentially a similar issue with TCE tables.

I understand what you are trying to do (though I told you I don't think
it's the right approach ;-) but heh... send a patch we'll see what it
looks like.

Cheers,
Ben.

Re: rtas instantiation when commandline contains mem

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Fri, 2009-07-17 at 08:36 +0200, Benjamin Krill wrote:
> >> the rtas instantiation (prom_init.c) doesn't work correctly if the
> >> kernel parameter "mem=" is used. The current code doesn't evaluate
> >> the kernel parameter which causes the issue that alloc_down
> >> allocates somewhere in the "real" memory space. So it can
> >> happen that the allocation space is above "mem=".
> >> 
> >> Commit 2babf5c2ec2f2d5de3e38d20f7df7fd815fd10c9 removes the
> >> evaluation of "mem=".
> >
> >Ah yes, we don't constraint prom_init.c to mem=, only the kernel
> 
> Is that with intent? Or should I provide a patch to include it again?

It was, it seemed to me that mem=x was about limiting kernel memory,
which RTAS isn't really. But I guess it depends how you look at it, and
what you're trying to do.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]