2.6.15-mm4 failure on power5

[Andrew Morton]

"Serge E. Hallyn" <serue at us.ibm.com> wrote:
>
> On my power5 partition, 2.6.15-mm4 hangs on boot with the following
>  console output.  2.6.15-mm3 booted fine.  .config attached.
> 
>  boot: quicktest
>  Please wait, loading kernel...
>     Elf64 kernel loaded...
>  OF stdout device is: /vdevice/vty at 30000000
>  Hypertas detected, assuming LPAR !
>  command line: ro console=hvc0 root=/dev/sda6 smt-enabled=1 
>  memory layout at init:
>    memory_limit : 0000000000000000 (16 MB aligned)
>    alloc_bottom : 0000000002223000
>    alloc_top    : 0000000008000000
>    alloc_top_hi : 0000000088000000
>    rmo_top      : 0000000008000000
>    ram_top      : 0000000088000000
>  Looking for displays
>  instantiating rtas at 0x00000000077d7000 ... done
>  0000000000000000 : boot cpu     0000000000000000
>  0000000000000002 : starting cpu hw idx 0000000000000002... done
>  0000000000000004 : starting cpu hw idx 0000000000000004... done
>  0000000000000006 : starting cpu hw idx 0000000000000006... done
>  copying OF device tree ...
>  Building dt strings...
>  Building dt structure...
>  Device tree strings 0x0000000002424000 -> 0x0000000002424f36
>  Device tree struct  0x0000000002425000 -> 0x000000000242c000
>  Calling quiesce ...
>  returning from prom_init
>  Page orders: linear mapping = 24, others = 12

It might be worth reverting the changes to arch/powerpc/mm/hash_utils_64.c,
see if that unbreaks it.

-		base = lmb.memory.region[i].base + KERNELBASE;
+		base = (unsigned long)__va(lmb.memory.region[i].base);

The nice comment in page.h:

 * KERNELBASE is the virtual address of the start of the kernel, it's often
 * the same as PAGE_OFFSET, but _might not be_.
 *
 * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
 *
 * To get a physical address from a virtual one you subtract PAGE_OFFSET,
 * _not_ KERNELBASE.

Tells us that was not an equivalent transformation.