linux-mips
[Top] [All Lists]

Re: Tracking down exception in sched.c

To: "Kevin D. Kissell" <kevink@mips.com>, "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:40:05 +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> <43F9C58E.4020606@mips.com>
Sender: linux-mips-bounce@linux-mips.org
>... if your phys_cpu_present_map
> (which is by default what gets used in MIPS as cpu_possible_map
> for the purposes of sched.c) is being properly initialized and
> maintained, the behavior of the two loops should be the same.
> Have you double-checked that?  Secondary CPUs turn generally
> set their bits in that mask in prom_build_cpu_map().

Correction.  I misremembered this.  prom_build_cpu_map()
is called only by the primary/boot CPU, prior to SMP initialization.
It's still the place where phys_cpu_present gets set up, but it
can't be set up by the secondaries.

            Regards,

            Kevin K.

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