2.6.16rc5 'found' an extra CPU.

DISCUSSION Chuck Ebbert 3 participants 4 messages Mar 2, 2006 – Mar 5, 2006 ACPI

lore

Share & tools

lore

Chuck Ebbert

author

2006-03-02 00:57 UTC #0 lore raw

In-Reply-To: <[email protected]>

Quoted 6 lines · Dave Jones

(17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002

Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?

Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.

Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS or something?

Signature · 2 lines

Chuck
"The sleet in Crete falls neatly in the street."

Dave Jones

2006-03-02 01:10 UTC #1 lore raw

Quoted 9 lines · Chuck Ebbert

In-Reply-To: <[email protected]>

Quoted 5 lines · Dave Jones

(17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002

Quoted 6 lines

Quoted 1 line
Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS or something?

Yes, it's =256.

Dave

Andrew Morton

2006-03-05 00:44 UTC #2 lore raw

Quoted 11 lines · Dave Jones

Quoted 9 lines · Chuck Ebbert

In-Reply-To: <[email protected]>

Quoted 5 lines · Dave Jones

(17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002

Quoted 9 lines

Quoted 6 lines
Quoted 1 line
Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS or something?
Yes, it's =256.

Is that the only way in which to trigger the bug?

If so, I'd be inclined to hold the fix back for 2.6.17.

From: Ashok Raj <[email protected]>

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 <[email protected]>

Cc "Brown, Len" <[email protected]>

Cc Dave Jones <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

---

 drivers/acpi/processor_core.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

drivers/acpi/processor_core.c renamed from drivers/acpi/processor_core.c~acpi-signedness-fix-2 +5 -5

diff -puN drivers/acpi/processor_core.c~acpi-signedness-fix-2 drivers/acpi/processor_core.c
@@ -382,7 +382,7 @@ static int acpi_processor_remove_fs(stru
 
 /* Use the acpiid in MADT to map cpus in case of SMP */
 #ifndef CONFIG_SMP
-#define convert_acpiid_to_cpu(acpi_id) (0xff)
+#define convert_acpiid_to_cpu(acpi_id) (-1)
 #else
 
 #ifdef CONFIG_IA64

@@ -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,

Dave Jones

2006-03-05 02:26 UTC #3 lore raw

Quoted 19 lines · Andrew Morton

Quoted 18 lines · Dave Jones
Quoted 15 lines · Chuck Ebbert
In-Reply-To: <[email protected]>
Quoted 6 lines · Dave Jones
(17:59:38:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu0/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
(17:59:47:davej@nemesis:~)$ cat /sys/devices/system/cpu/cpu1/topology/core_siblings
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000002
Neither of these CPUs are HT / dual-core, so shouldn't these be the same ?
Those are bitmaps. 1 => only bit 0 is set => CPU 0 is all alone.
Did you really build a 256-CPU SMP kernel or is ACPI ignoring CONFIG_NR_CPUS or something?

Quoted 6 lines

Quoted 2 lines
Yes, it's =256.
Is that the only way in which to trigger the bug?
If so, I'd be inclined to hold the fix back for 2.6.17.

not had chance to test Ashok's change yet (and probably won't until at least Monday), but Andi's one-liner to limit x86-64's NR_CPUs to 255 instead of 256 did the trick, and is a lot less invasive for 2.6.16

Dave