> > Any other suggestions, how to fix this?
>
> Almost certainly wrong - like almost any loop iterating over 0..NR_CPUS.
> I'm looking into this now. Part of what is blowing up is this piece of
> legacy code
>
> #define cpu_possible_map phys_cpu_present_map
>
> in include/asm-mips/smp.h. Time to clean that and I fear it's not going
> to be pretty ...
I don't think anything's necessarily broken there except for a lack of
documentation. That #define will presumably go away once hot-plug support
is fully in, but the fact that the boot code sets up a phys_cpu_present_map
is perfectly reasonable, and equating that to cpu_possible_map for the purposes
of sched.c is simple and efficient. Whatever name it has, if the platform code
doesn't correctly initialize and maintain the map, Bad Things will clearly happen.
I'm not sure how we can actually prevent this. It pretty much has to be
platform-specific code that determines whether a given CPU is present
in a hardware configuration.
Regards,
Kevin K.
