mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrew Morton <akpm@osdl.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org,
	jun.nakajima@intel.com, "Brown, Len" <len.brown@intel.com>
Subject: Re: [PATCH] bug in bigsmp CPU bringup
Date: Wed, 05 May 2004 22:27:30 -0700	[thread overview]
Message-ID: <494600000.1083821250@[10.10.2.4]> (raw)
In-Reply-To: <20040505190332.395cac70.akpm@osdl.org>

> Len, Martin: please review?

Looked already (in fact I suggested he do that). Looks fine, it's 
exactly the same fix we use for Summit.  Since we're using the other
method instead of the bitmap, this check isn't needed, so we can just
bypass it. This way also has the great advantage of being isolated
to the bigsmp subarch, so it only needs testing there ;-)

Thanks,

M.

> 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)
> 
> _
> 
> 



      reply	other threads:[~2004-05-06  5:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-06  1:43 Pallipadi, Venkatesh
2004-05-06  2:03 ` Andrew Morton
2004-05-06  5:27   ` Martin J. Bligh [this message]

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='494600000.1083821250@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=akpm@osdl.org \
    --cc=jun.nakajima@intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 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®