lkml.org 
[lkml]   [2005]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] PPC64 NUMA memory fixup
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:11    [W:0.059 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site