public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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