Re: Tracking down exception in sched.c

["Kevin D. Kissell" <kevink@mips.com>]

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 prom_build_cpu_map()
is still invoked explicitly from smp_prepare_cpus(), just before prom_prepare_cpus().
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...

		Regards,

		Kevin K.

diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 5e18986..7ec9579 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -236,7 +236,6 @@ void __init smp_prepare_cpus(unsigned in
         init_new_context(current, &init_mm);
         current_thread_info()->cpu = 0;
         smp_tune_scheduling();
-       prom_prepare_cpus(max_cpus);
  }

  /* preload SMP state for boot cpu */
@@ -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);
  }

  /*