[PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.

Josh Boyer jwboyer at gmail.com
Sat Nov 1 22:30:18 EST 2008


On Fri, Oct 31, 2008 at 06:23:28PM -0500, Hollis Blanchard wrote:
>On Wed, Oct 22, 2008 at 9:28 AM, Christian Ehrhardt
><ehrhardt at linux.vnet.ibm.com> wrote:
>> Hi Ilya,
>> I just tried your patch on my 440 board because it would help us in our
>> environment.
>> Unfortunately I run into a bug on early boot (mark_bootmem).
>>
>> A log can be found in this mail, this is the bug when running with 64k page
>> size.
>> I tried this with and without your 2/2 265k patch and also with page size
>> configured to 16k, the error is the same in all cases.
>>
>> I used an earlier version of your patch in the past and it worked fine.
>> Applying this old patch causes the same problem.
>> Therefore I expect that there was some other code changed that breaks with
>> page size != 4k.
>
>This patch seems to solve the problem for me, but I have to run and
>haven't yet worked out if it's the right fix.
>
>diff --git a/mm/bootmem.c b/mm/bootmem.c
>--- a/mm/bootmem.c
>+++ b/mm/bootmem.c
>@@ -300,7 +300,7 @@ static int __init mark_bootmem(unsigned
>                unsigned long max;
>
>                if (pos < bdata->node_min_pfn ||
>-                   pos >= bdata->node_low_pfn) {
>+                   pos > bdata->node_low_pfn) {
>                        BUG_ON(pos != start);
>                        continue;
>                }
>@@ -399,7 +399,7 @@ int __init reserve_bootmem(unsigned long
>        unsigned long start, end;
>
>        start = PFN_DOWN(addr);
>-       end = PFN_UP(addr + size);
>+       end = PFN_DOWN(addr + size);
>
>        return mark_bootmem(start, end, 1, flags);
> }
>
>Looks like the breakage may have been accidentally introduced by
>Johannes Weiner <hannes at saeurebad.de> on Jul 24 (post 2.6.26).
>
>FWIW, the boards Christian and I are hitting the problem on are
>Sequoias with 256MB of RAM. cuImage is reporting only 0xffff000 bytes
>of RAM though, which may be exacerbating the situation.

That is on purpose.  The chip has an errata that causes badness if
you use the last XX bytes of DRAM.  I forget exactly what XX is, but
we just remove the last page.

josh



More information about the Linuxppc-dev mailing list