From: Andrew Morton <akpm@osdl.org>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org,
jun.nakajima@intel.com, "Martin J. Bligh" <mbligh@aracnet.com>,
"Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH] bug in bigsmp CPU bringup
Date: Wed, 5 May 2004 19:03:32 -0700 [thread overview]
Message-ID: <20040505190332.395cac70.akpm@osdl.org> (raw)
In-Reply-To: <88056F38E9E48644A0F562A38C64FB6001BFF5A9@scsmsx403.sc.intel.com>
Len, Martin: please review?
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
There is an bug in bigsmp sub-architecture, due to which it will not enable
all the CPUs when the BIOS-APICIDs are not 0 to n-1 (where n is total
number of CPUs). Particularly, only 2 CPU comes up on a system that has 4
CPUs with BIOS APICID as (0, 1, 6, 7).
The bug is root caused to check_apicid_present(bit) call in smpboot.c, when
bigsmp is expecting apicid in place of bit. check_apicid_present(bit) in
bigsmp subarchitecture checks the bit with phys_id_present_map (which is
actually map representing all apicids and not bit).
One solution is to change check_apicid_present(bit) to
check_apicid_present(apicid), in smp_boot_cpus(). But, it can affect all
the other subarchitectures in various subtle ways. So, here is a simple
alternate fix (Thanks to Martin Bligh), which solves the above problem.
---
25-akpm/include/asm-i386/mach-bigsmp/mach_apic.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN include/asm-i386/mach-bigsmp/mach_apic.h~bigsmp-cpu-bringup-fix include/asm-i386/mach-bigsmp/mach_apic.h
--- 25/include/asm-i386/mach-bigsmp/mach_apic.h~bigsmp-cpu-bringup-fix 2004-05-05 19:02:18.299905696 -0700
+++ 25-akpm/include/asm-i386/mach-bigsmp/mach_apic.h 2004-05-05 19:02:18.302905240 -0700
@@ -37,9 +37,10 @@ static inline unsigned long check_apicid
return 0;
}
+/* we don't use the phys_cpu_present_map to indicate apicid presence */
static inline unsigned long check_apicid_present(int bit)
{
- return physid_isset(bit, phys_cpu_present_map);
+ return 1;
}
#define apicid_cluster(apicid) (apicid & 0xF0)
_
next prev parent reply other threads:[~2004-05-06 2:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-06 1:43 [PATCH] bug in bigsmp CPU bringup Pallipadi, Venkatesh
2004-05-06 2:03 ` Andrew Morton [this message]
2004-05-06 5:27 ` Martin J. Bligh
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=20040505190332.395cac70.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=jun.nakajima@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=torvalds@osdl.org \
--cc=venkatesh.pallipadi@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.