From: Andrew Morton <akpm@osdl.org>
Cc: davej@redhat.com, ashok.raj@intel.com, len.brown@intel.com,
ak@suse.de, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: 2.6.16rc5 'found' an extra CPU.
Date: Thu, 2 Mar 2006 23:14:52 -0800 [thread overview]
Message-ID: <20060302231452.440a91c8.akpm@osdl.org> (raw)
In-Reply-To: <20060302112119.A13035@unix-os.sc.intel.com>
Ashok Raj <ashok.raj@intel.com> wrote:
>
> Local apic entries are only 8 bits, but it seemed to not be caught with
> u8 return value result in the check
>
> cpu_index >= NR_CPUS becomming always false.
>
> drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
> drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
>
>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> -----------------------------------------------------
> drivers/acpi/processor_core.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> ===================================================================
> --- linux-2.6.16-rc5-mm1.orig/drivers/acpi/processor_core.c
> +++ linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> @@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
> #define ARCH_BAD_APICID (0xff)
> #endif
>
> -static u8 convert_acpiid_to_cpu(u8 acpi_id)
> +static int convert_acpiid_to_cpu(u8 acpi_id)
> {
> u16 apic_id;
> int i;
> @@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
> acpi_status status = 0;
> union acpi_object object = { 0 };
> struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
> - u8 cpu_index;
> + int cpu_index;
> static int cpu0_initialized;
>
> ACPI_FUNCTION_TRACE("acpi_processor_get_info");
> @@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
> cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
>
> /* Handle UP system running SMP kernel, with no LAPIC in MADT */
> - if (!cpu0_initialized && (cpu_index == 0xff) &&
> + if (!cpu0_initialized && (cpu_index == -1) &&
> (num_online_cpus() == 1)) {
> cpu_index = 0;
> }
> @@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
> * less than the max # of CPUs. They should be ignored _iff
> * they are physically not present.
> */
> - if (cpu_index >= NR_CPUS) {
> + if (cpu_index == -1) {
> if (ACPI_FAILURE
> (acpi_processor_hotadd_init(pr->handle, &pr->id))) {
> ACPI_ERROR((AE_INFO,
On a uniprocessor build this causes a crash in acpi_processor_start():
BUG_ON((pr->id >= NR_CPUS) || (pr->id < 0));
pr->id is 255.
I could bodge around this in various ways, but the semantics of cpu IDs in
there seem to be a bit opaque, and I suspect some more thought needs to go
into it all.
As well as uniprocessor testing ;)
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: Ashok Raj <ashok.raj@intel.com>
Cc: davej@redhat.com, ashok.raj@intel.com, len.brown@intel.com,
ak@suse.de, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: 2.6.16rc5 'found' an extra CPU.
Date: Thu, 2 Mar 2006 23:14:52 -0800 [thread overview]
Message-ID: <20060302231452.440a91c8.akpm@osdl.org> (raw)
In-Reply-To: <20060302112119.A13035@unix-os.sc.intel.com>
Ashok Raj <ashok.raj@intel.com> wrote:
>
> Local apic entries are only 8 bits, but it seemed to not be caught with
> u8 return value result in the check
>
> cpu_index >= NR_CPUS becomming always false.
>
> drivers/acpi/processor_core.c: In function `acpi_processor_get_info':
> drivers/acpi/processor_core.c:483: warning: comparison is always false due to limited range of data type
>
>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> -----------------------------------------------------
> drivers/acpi/processor_core.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> ===================================================================
> --- linux-2.6.16-rc5-mm1.orig/drivers/acpi/processor_core.c
> +++ linux-2.6.16-rc5-mm1/drivers/acpi/processor_core.c
> @@ -395,7 +395,7 @@ static int acpi_processor_remove_fs(stru
> #define ARCH_BAD_APICID (0xff)
> #endif
>
> -static u8 convert_acpiid_to_cpu(u8 acpi_id)
> +static int convert_acpiid_to_cpu(u8 acpi_id)
> {
> u16 apic_id;
> int i;
> @@ -421,7 +421,7 @@ static int acpi_processor_get_info(struc
> acpi_status status = 0;
> union acpi_object object = { 0 };
> struct acpi_buffer buffer = { sizeof(union acpi_object), &object };
> - u8 cpu_index;
> + int cpu_index;
> static int cpu0_initialized;
>
> ACPI_FUNCTION_TRACE("acpi_processor_get_info");
> @@ -466,7 +466,7 @@ static int acpi_processor_get_info(struc
> cpu_index = convert_acpiid_to_cpu(pr->acpi_id);
>
> /* Handle UP system running SMP kernel, with no LAPIC in MADT */
> - if (!cpu0_initialized && (cpu_index == 0xff) &&
> + if (!cpu0_initialized && (cpu_index == -1) &&
> (num_online_cpus() == 1)) {
> cpu_index = 0;
> }
> @@ -480,7 +480,7 @@ static int acpi_processor_get_info(struc
> * less than the max # of CPUs. They should be ignored _iff
> * they are physically not present.
> */
> - if (cpu_index >= NR_CPUS) {
> + if (cpu_index == -1) {
> if (ACPI_FAILURE
> (acpi_processor_hotadd_init(pr->handle, &pr->id))) {
> ACPI_ERROR((AE_INFO,
On a uniprocessor build this causes a crash in acpi_processor_start():
BUG_ON((pr->id >= NR_CPUS) || (pr->id < 0));
pr->id is 255.
I could bodge around this in various ways, but the semantics of cpu IDs in
there seem to be a bit opaque, and I suspect some more thought needs to go
into it all.
As well as uniprocessor testing ;)
next prev parent reply other threads:[~2006-03-03 7:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-02 5:49 2.6.16rc5 'found' an extra CPU Brown, Len
2006-03-02 5:49 ` Brown, Len
2006-03-02 9:33 ` Romano Giannetti
2006-03-02 15:53 ` Zwane Mwaikambo
2006-03-02 15:58 ` Romano Giannetti
2006-03-02 12:14 ` Andi Kleen
2006-03-02 16:30 ` Ashok Raj
2006-03-02 18:44 ` Dave Jones
2006-03-02 19:21 ` Ashok Raj
2006-03-03 7:14 ` Andrew Morton [this message]
2006-03-03 7:14 ` Andrew Morton
2006-03-03 17:41 ` Ashok Raj
-- strict thread matches above, loose matches on Subject: below --
2006-03-02 19:37 Brown, Len
2006-03-02 19:26 Brown, Len
2006-03-02 19:31 ` Dave Jones
2006-03-02 19:33 ` Andi Kleen
2006-03-02 19:18 Brown, Len
2006-03-02 19:18 ` Brown, Len
2006-03-02 19:16 Brown, Len
2006-03-02 19:16 ` Brown, Len
2006-03-02 17:34 Brown, Len
2006-03-02 17:34 ` Brown, Len
2006-03-02 17:30 Brown, Len
2006-03-02 17:30 ` Brown, Len
2006-03-02 0:55 Chuck Ebbert
2006-03-02 1:09 ` Dave Jones
2006-03-05 0:42 ` Andrew Morton
2006-03-05 2:26 ` Dave Jones
2006-03-01 23:01 Moore, Robert
2006-03-01 23:01 ` Moore, Robert
2006-03-01 22:46 Dave Jones
2006-03-01 23:03 ` Dave Jones
2006-03-02 0:55 ` Andi Kleen
2006-03-02 1:19 ` Dave Jones
2006-03-02 1:38 ` Andi Kleen
2006-03-02 3:13 ` Dave Jones
2006-03-02 3:24 ` Andi Kleen
2006-03-02 3:45 ` Dave Jones
2006-03-02 3:52 ` Ashok Raj
2006-03-02 4:11 ` Dave Jones
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=20060302231452.440a91c8.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ak@suse.de \
--cc=ashok.raj@intel.com \
--cc=davej@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.