linux-mips
[Top] [All Lists]

Re: Tracking down exception in sched.c

To: "Ralf Baechle" <ralf@linux-mips.org>, "Rojhalat Ibrahim" <imr@rtschenk.de>
Subject: Re: Tracking down exception in sched.c
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Mon, 20 Feb 2006 15:35:58 +0100
Cc: "Mark E Mason" <mark.e.mason@broadcom.com>, <linux-mips@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <7E000E7F06B05C49BDBB769ADAF44D0773A636@NT-SJCA-0750.brcm.ad.broadcom.com> <43F9B168.6090105@rtschenk.de> <20060220133527.GA10598@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
> > 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.

<Prev in Thread] Current Thread [Next in Thread>