Kevin D. Kissell wrote:
The behavior of the two loops is not the same because sched_init
is called long before smp_prepare_cpus. Therefore for_each_cpu
only loops once for CPU 0. I know this is not a great fix.
I simply reverted the code to what's worked before.
It's certainly the code that I'm still using! ;o) So prom_build_cpu_map
needs to be called earlier (as in maybe from smp_prepare_boot_cpu?).
OK, when I wrote the above, I was blinded by the fact that I'm personally
doing my SMP (SMTC) work on a downrev development tree, where
is still invoked explicitly from smp_prepare_cpus(), just before
In those sources, I was able to do what I describe and have the for_each_cpu()
in sched_init() work fine.
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...
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 5e18986..7ec9579 100644
@@ -236,7 +236,6 @@ void __init smp_prepare_cpus(unsigned in
current_thread_info()->cpu = 0;
/* preload SMP state for boot cpu */
@@ -251,6 +250,8 @@ void __devinit smp_prepare_boot_cpu(void
+ /* This is done early to populate phys_cpu_present_map for sched_init */