mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Cleverdon <jamesclv@us.ibm.com>
To: john stultz <johnstul@us.ibm.com>, lkml <linux-kernel@vger.kernel.org>
Cc: keith maanthey <kmannth@us.ibm.com>
Subject: Re: [RFC][PATCH] linux-2.4.23-pre7_cpu-map-fix_A0
Date: Wed, 22 Oct 2003 13:25:49 -0700	[thread overview]
Message-ID: <200310221325.49351.jamesclv@us.ibm.com> (raw)
In-Reply-To: <1066847057.1119.63.camel@cog.beaverton.ibm.com>

Works for me.  That code needs a thorough overhaul when 2.6 stabilizes.  It's 
far more complex than is necessary.


On Wednesday 22 October 2003 11:24 am, john stultz wrote:
> All,
> 	I noticed on x440s that when HT is disabled in the BIOS I was having
> problems properly booting 2.4 in ACPI mode. Further investigation found
> a subtle problem w/ smp_boot_cpus() when clustered_acpi_mode is set.
>
> During bootup, phys_cpu_present_map is initialized by ORing
> apicid_to_phys_cpu_present() for each cpu apicid(see MP_processor_info).
> On flat mode boxes this translates to "phys_cpu_present_map |=
> (1<<apicid)".
>
> On clustered_apic_mode boxes, since we're using phyiscal apic addresses,
> the apicids are not sequential so it is possible the
> phys_cpu_present_map can have holes in it (see
> apicid_to_phys_cpu_present()).
>
> The problem arises in smp_boot_cpus() because when we are booting the
> cpus, we iterate through each apicid, however we bit-AND
> phys_cpu_present_map w/ (1<<apicid)  rather then using
> apicid_to_phys_cpu_present(apicid). This may cause us to try to boot
> apicids that do not exist.
>
> The following patch corrects the problem by always bit-ANDing
> phys_cpu_present_map with apicid_to_phys_cpu_present(). This is safe for
> flat mode boxes, as apicid_to_phys_cpu_present(apicid) translates to
> (1<<apicid).
>
> Additionally, the patch insures we do not try to boot BAD_APICIDs and
> removes a hack that was added to mpparse.c which worked around this
> problem in the non-ACPI boot path.
>
> In 2.5 we do not have this problem as we use logical rather then
> physical apic addressing.
>
> Any Comments or feedback would be greatly appreciated.
>
> thanks
> -john
>
>
> diff -Nru a/arch/i386/kernel/mpparse.c b/arch/i386/kernel/mpparse.c
> --- a/arch/i386/kernel/mpparse.c	Tue Oct 21 19:13:36 2003
> +++ b/arch/i386/kernel/mpparse.c	Tue Oct 21 19:13:36 2003
> @@ -587,10 +587,6 @@
>  		++mpc_record;
>  	}
>
> -	if (clustered_apic_mode){
> -		phys_cpu_present_map = logical_cpu_present_map;
> -	}
> -
>
>  	printk("Enabling APIC mode: ");
>  	if(clustered_apic_mode == CLUSTERED_APIC_NUMAQ)
> diff -Nru a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
> --- a/arch/i386/kernel/process.c	Tue Oct 21 19:13:36 2003
> +++ b/arch/i386/kernel/process.c	Tue Oct 21 19:13:36 2003
> @@ -44,6 +44,7 @@
>  #include <asm/irq.h>
>  #include <asm/desc.h>
>  #include <asm/mmu_context.h>
> +#include <asm/smpboot.h>
>  #ifdef CONFIG_MATH_EMULATION
>  #include <asm/math_emu.h>
>  #endif
> @@ -377,7 +378,7 @@
>  		   if its not, default to the BSP */
>  		if ((reboot_cpu == -1) ||
>  		      (reboot_cpu > (NR_CPUS -1))  ||
> -		      !(phys_cpu_present_map & (1<<cpuid)))
> +		      !(phys_cpu_present_map & apicid_to_phys_cpu_present(cpuid)))
>  			reboot_cpu = boot_cpu_physical_apicid;
>
>  		reboot_smp = 0;  /* use this as a flag to only go through this once*/
> diff -Nru a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c
> --- a/arch/i386/kernel/smpboot.c	Tue Oct 21 19:13:36 2003
> +++ b/arch/i386/kernel/smpboot.c	Tue Oct 21 19:13:36 2003
> @@ -1108,13 +1108,17 @@
>
>  	for (bit = 0; bit < NR_CPUS; bit++) {
>  		apicid = cpu_present_to_apicid(bit);
> +
> +		/* don't try to boot BAD_APICID */
> +		if (apicid == BAD_APICID)
> +			continue;
>  		/*
>  		 * Don't even attempt to start the boot CPU!
>  		 */
>  		if (apicid == boot_cpu_apicid)
>  			continue;
>
> -		if (!(phys_cpu_present_map & (1ul << bit)))
> +		if (!(phys_cpu_present_map & apicid_to_phys_cpu_present(apicid)))
>  			continue;
>  		if (max_cpus <= cpucount+1)
>  			continue;
> @@ -1125,7 +1129,8 @@
>  		 * Make sure we unmap all failed CPUs
>  		 */
>  		if ((boot_apicid_to_cpu(apicid) == -1) &&
> -				(phys_cpu_present_map & (1ul << bit)))
> +			(phys_cpu_present_map &
> +				apicid_to_phys_cpu_present(apicid)))
>  			printk("CPU #%d/0x%02x not responding - cannot use it.\n",
>  								bit, apicid);
>  	}

-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm

      reply	other threads:[~2003-10-22 20:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-22 18:24 john stultz
2003-10-22 20:25 ` James Cleverdon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200310221325.49351.jamesclv@us.ibm.com \
    --to=jamesclv@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=kmannth@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome