From: Christoph Hellwig <hch@infradead.org>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Martin Bligh <mbligh@us.ibm.com>,
John Stultz <johnstul@us.ibm.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
jamesclv@us.ibm.com, "Mallick, Asit K" <asit.k.mallick@intel.com>,
"Saxena, Sunil" <sunil.saxena@intel.com>
Subject: Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
Date: Wed, 18 Dec 2002 23:26:40 +0000 [thread overview]
Message-ID: <20021218232640.A1746@infradead.org> (raw)
In-Reply-To: <C8C38546F90ABF408A5961FC01FDBF1912E18E@fmsmsx405.fm.intel.com>; from venkatesh.pallipadi@intel.com on Wed, Dec 18, 2002 at 02:36:20PM -0800
On Wed, Dec 18, 2002 at 02:36:20PM -0800, Pallipadi, Venkatesh wrote:
> These reasons together led to panics on other OEM systems with > 8 CPUS. The
> patch tries to fix this issue in a generic way (in place of having multiple
> hacks for different OEMs). Note, the patch only intends to change the
> initialization of systems with more than 8 CPUs and it will not affect
> other systems (apart from possible bugs in my code itself).
Any pointers to these systems?
> - Separate out xAPIC stuff from APIC destination setup. And the availability of
> xAPIC support can actually be determined from the LAPIC version.
Are you sure? IIRC some of the early summit boxens didn't report the
right versions..
> - physical mode support _removed_, as we can use clustered logical setup to
> support can support upto a max of 60 CPUs. This is mainly because of the
> advantage of being able to setup IOAPICs in LowestPrio, when using clustered mode.
does this really not break anything in the fragile summit setups?
- bool 'Multi-node NUMA system support' CONFIG_X86_NUMA
- if [ "$CONFIG_X86_NUMA" = "y" ]; then
+ bool 'Clustered APIC (> 8 CPUs) support' CONFIG_X86_APIC_CLUSTER
+ if [ "$CONFIG_X86_APIC_CLUSTER" = "y" ]; then
+ define_bool CONFIG_X86_CLUSTERED_APIC y
Do we really need CONFIG_X86_APIC_CLUSTER _and_ CONFIG_X86_CLUSTERED_APIC?
unsigned long id;
- if(clustered_apic_mode == CLUSTERED_APIC_XAPIC)
- id = physical_to_logical_apicid(hard_smp_processor_id());
+ if(clustered_apic_mode)
+ id = cpu_2_logical_apicid[smp_processor_id()];
else
Okay, this was wrong before, but any chance you could use proper
style here (i.e. if ()
id = 1UL << smp_processor_id();
- if (mp_ioapics[apic].mpc_apicid >= apic_broadcast_id) {
+ if ( !xapic_support &&
+ (mp_ioapics[apic].mpc_apicid >= apic_broadcast_id)) {
if (!xapic_support &&
(mp_ioapics[apic].mpc_apicid >= apic_broadcast_id)) {
+ if ( !xapic_support ) {
Again.
- if (clustered_apic_mode == CLUSTERED_APIC_NUMAQ) {
+ if (clustered_apic_mode &&
+ (configured_platform_type == CONFIGURED_PLATFORM_NUMA) ) {
Doesn;t configured_platform_type == CONFIGURED_PLATFORM_NUMA imply
clustered_apic_mode? and it should be at least CONFIGURED_PLATFORM_NUMAQ,
btw. Probably better something short like SUBARCH_NUMAQ..
Except of that the patch looks fine, but IMHO something like that should
get testing in 2.5 first.
next prev parent reply other threads:[~2002-12-18 23:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-18 22:36 [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs Pallipadi, Venkatesh
2002-12-18 23:26 ` Christoph Hellwig [this message]
2002-12-18 23:41 ` William Lee Irwin III
2002-12-18 23:59 ` Martin J. Bligh
2002-12-19 0:24 ` Martin J. Bligh
2002-12-20 2:04 ` James Cleverdon
2002-12-20 8:00 ` Christoph Hellwig
2002-12-20 11:24 ` William Lee Irwin III
2002-12-20 11:29 ` William Lee Irwin III
-- strict thread matches above, loose matches on Subject: below --
2002-12-19 1:05 Pallipadi, Venkatesh
2002-12-19 1:32 ` James Cleverdon
2002-12-19 2:35 Pallipadi, Venkatesh
2002-12-19 3:10 ` Martin J. Bligh
2002-12-19 2:45 Pallipadi, Venkatesh
2002-12-19 4:14 ` James Cleverdon
2002-12-21 3:27 Nakajima, Jun
2002-12-21 4:43 ` Martin J. Bligh
2003-01-07 22:42 Andrew Theurer
2003-01-11 4:28 ` James Cleverdon
2003-01-08 3:19 Kamble, Nitin A
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=20021218232640.A1746@infradead.org \
--to=hch@infradead.org \
--cc=asit.k.mallick@intel.com \
--cc=jamesclv@us.ibm.com \
--cc=johnstul@us.ibm.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@us.ibm.com \
--cc=sunil.saxena@intel.com \
--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.