Re: [PATCH] PPC64 NUMA memory fixup

[Paul Mackerras <paulus@samba.org>]

Andrew Morton writes:

> This patch causes the non-numa G5 to oops very early in boot in
> smp_call_function().

Hmmm, the reason we are getting into smp_call_function is that we have
panicked due to not being able to allocate boot memory.  It's kind of
sad that we can't even panic successfully, although this is very
early: we haven't got through setup_arch yet.  The immediate reason
for the panic is that smp_ops is uninitialized.  We seem to be looking
at smp_ops because num_online_cpus() is not 1; I assume it is 0 at
this point.

Anyway, the ultimate reason seems to be that the numa.c code is
assuming that an address value and a size value occupy the same number
of cells.  On the G5 we have #address-cells = 2 but #size-cells = 1.
Previously this didn't matter because we used the values in lmb.memory
for the free_bootmem_node calls.  Those values are obtained in prom.c
by scanning the memory nodes, using the correct number of cells.  With
Mike's patch we rely instead on the values obtained by the numa.c
code, which uses read_cell_ul() for both address and size values, and
that just uses prom_n_size_cells() to know how many cells to parse.
It really needs to use prom_n_addr_cells() when parsing an address
value.

Paul.