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

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);
 	}




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

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

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=1066847057.1119.63.camel@cog.beaverton.ibm.com \
    --to=johnstul@us.ibm.com \
    --cc=jamesclv@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

all inboxes | Powered by JetHome®