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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox