Hello, On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote: > On Mon, 19 May 2014, Nishanth Aravamudan wrote: > > I'm seeing a panic at boot with this change on an LPAR which actually > > has no Node 0. Here's what I think is happening: > > > > start_kernel > > ... > > -> setup_per_cpu_areas > > -> pcpu_embed_first_chunk > > -> pcpu_fc_alloc > > -> ___alloc_bootmem_node(NODE_DATA(cpu_to_node(cpu), ... > > -> smp_prepare_boot_cpu > > -> set_numa_node(boot_cpuid) > > > > So we panic on the NODE_DATA call. It seems that ia64, at least, uses > > pcpu_alloc_first_chunk rather than embed. x86 has some code to handle > > early calls of cpu_to_node (early_cpu_to_node) and sets the mapping for > > all CPUs in setup_per_cpu_areas(). > > Maybe we can switch ia64 too embed? Tejun: Why are there these > dependencies? > > > Thoughts? Does that mean we need something similar to x86 for powerpc? I'm missing context to properly understand what's going on but the specific allocator in use shouldn't matter. e.g. x86 can use both embed and page allocators. If the problem is that the arch is accessing percpu memory before percpu allocator is initialized and the problem was masked before somehow, the right thing to do would be removing those premature percpu accesses. If early percpu variables are really necessary, doing similar early_percpu thing as in x86 would be necessary. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>