On Mon, Feb 20, 2006 at 09:27:39PM +0100, Kevin D. Kissell wrote: > But apparently current sources no longer even invoke prom_build_cpu_map(), > having merged that functionality with prom_prepare_cpus(). It looks to me > as if calling prom_prepare_cpus() from smp_prepare_boot_cpu() as in the > patch below, should do the right thing in all current cases, but it *is* > standing the SMP startup logic a bit on its head. Maybe this is why > prom_build_cpu_map() had a separate existence in the first place... Primarily historic reasons actuall. In 2.4 mips and mips64 used to be separate and evolution did diverge a bit in the SMP area and this is the radioactive fallout from it ;-) > @@ -251,6 +250,8 @@ void __devinit smp_prepare_boot_cpu(void > cpu_set(0, phys_cpu_present_map); > cpu_set(0, cpu_online_map); > cpu_set(0, cpu_callin_map); > + /* This is done early to populate phys_cpu_present_map for > sched_init */ > + prom_prepare_cpus(max_cpus); > } Which won't compile because smp_prepare_boot_cpu doesn't define max_cpus. Anyway, prom_prepare_cpus was running very late and in the past that was causing problems with firmware which relies on it's mappings still being alive while the machine had already been taken over by Linux. The patch which I cooked up - and haven't yet been able to test yet since my barrel of midnight oil is about to run out - is calling it from setup_arch(). Ralf
