Re: Tracking down exception in sched.c

[Ralf Baechle <ralf@linux-mips.org>]

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