ppc64 oops..

[Paul Mackerras]

Linus Torvalds writes:

> Hmm. I _thought_ I had just 2GB (possibly 4GB) in this machine, but the 
> bootup says
> 
>   ...
>   [boot]0100 MM Init
>   IO Hole assumed to be 80000000 -> ffffffff
>   [boot]0100 MM Init Done
>   Linux version 2.6.15-rc1-g4060994c (torvalds at g5.osdl.org) (gcc version 4.0.1 200..
>   [boot]0012 Setup Arch
>   Top of RAM: 0x180000000, Total RAM: 0x100000000
>   Memory hole size: 2048MB

That says you have 4GB, 2GB at 0 and 2GB at 4G, with a 2G hole in
between.

> ie it seems to have set up the mem_map[] to point all the way down from 
> 6GB to 0, and then when I've used up the two high GB of memory (the _real_ 
> memory in this machine) it starts allocating memory that it doesn't have, 
> and that it doesn't have TLB mappings for.

Yep, looks that way.  I wonder why it hits 0xc0000000ff000000 before
(e.g.) 0xc0000000fffff000?

> No, looks like a ppc64 memory setup bug, altough it's quite possibly 
> brought on by the PageReserved() removal in the VM layer. 
> 
> Andrew, Nick, Hugh, I really think that removing that "PageReserved()" 
> test from the page freeing functions was a mistake. I think I'm going to 
> add it back in.
> 
> I bet this happens on all the other architectures too. The bootup has 
> marked pages reserved, and then frees them all. It used to be that the VM 
> just silently skipped the reserved pages, now it will add them to the free 
> lists..

Hmmm, the lmb structure that do_init_bootmem uses should have two
entries, and we should be doing free_bootmem(0, 2G) and
free_bootmem(4G, 2G), which I would have thought would do the right
thing.  A printk in there (arch/powerpc/mm/mem.c) would tell us...

Paul.