logical CPU numbering
PATCH 1/1 logical CPU numbering
Hello,
If a CPU fails to start during smp_boot_cpus(), then the logical CPU numbering gets will have a "hole". Using the number of booted CPU's instead of the loop index will correct this.
This patch is against 2.4.21-pre5.
thanks,
mh
Signature · 14 lines
Wild Open Source Inc. [email protected] --- linux-2.4.21-pre5-ia64-030312.pristine/arch/ia64/kernel/smpboot.c Sun Mar 16 10:18:53 2003 +++ linux-2.4.21-pre5-ia64-030312/arch/ia64/kernel/smpboot.c Thu Mar 20 10:47:07 2003 @@ -522,7 +522,7 @@ /* * Make sure we unmap all failed CPUs */ - if (ia64_cpu_to_sapicid[cpu] = -1) + if (ia64_cpu_to_sapicid[cpucount] = -1) printk("phys CPU#%d not responding - cannot use it.\n", cpu); }
Quoted 3 lines
If a CPU fails to start during
smp_boot_cpus(), then the logical CPU numbering gets will have a "hole". Using the number of booted CPU's instead of the loop index will correct this.
Just curious, does having a hole cause a problem? It might well; I don't know.
I consider some future scenario where if cpu X didn't come up, it can be hot-replaced, at which point one might actually want to have that "slot" reserved for it.
Quoted 5 lines · Mats D
Quoted 4 lines
If a CPU fails to start during
smp_boot_cpus(), then the logical CPU numbering gets will have a "hole". Using the number of booted CPU's instead of the loop index will correct this.
Quoted 7 lines
Just curious, does having a hole cause a problem? It might well; I don't know.
I consider some future scenario where if cpu X didn't come up, it can be hot-replaced, at which point one might actually want to have that "slot" reserved for it.
I thought there was some code that depended on having logical cpus numbered without holes. I can't find any evidence of it anymore, so perhaps its not a bug.
mh
Signature · 1 line
Wild Open Source Inc. [email protected]
Quoted 8 lines · Martin Hicks
Hello,
If a CPU fails to start during
smp_boot_cpus(), then the logical CPU numbering gets will have a "hole". Using the number of booted CPU's instead of the loop index will correct this.This patch is against 2.4.21-pre5.
This patch should be applied. I finally got around to doing some more testing with it. If a CPU fails to start, currently we get messages like the following for subsequent CPU's:
CPU 17: nasid 18, slice 0, cnode 9
CPU 17: base freq 0.000MHz, ITC ratio/2, ITC freq00.000MHz Calibrating delay loop... 1494.72 BogoMIPS
phys CPU#17 (0x12) not responding - cannot use it. <<-BOGUS
The patch below fixes this problem. This is the same patch as before, reposted just to make things easier. It is against 2.4.21-pre5-ia64-0303012.
Thanks,
mh
Signature · 13 lines
Wild Open Source Inc. [email protected] --- linux-2.4.21-pre5-ia64-030312.pristine/arch/ia64/kernel/smpboot.c Sun Mar 16 10:18:53 2003 +++ linux-2.4.21-pre5-ia64-030312/arch/ia64/kernel/smpboot.c Thu Mar 20 10:47:07 2003 @@ -522,7 +522,7 @@ /* * Make sure we unmap all failed CPUs */ - if (ia64_cpu_to_sapicid[cpu] = -1) + if (ia64_cpu_to_sapicid[cpucount] = -1) printk("phys CPU#%d not responding - cannot use it.\n", cpu); }
Quoted 9 lines · Martin Hicks
This patch should be applied. I finally got around to doing some more testing with it. If a CPU fails to start, currently we get messages like the following for subsequent CPU's:
CPU 17: nasid 18, slice 0, cnode 9
CPU 17: base freq 0.000MHz, ITC ratio/2, ITC freq00.000MHz Calibrating delay loop... 1494.72 BogoMIPS
phys CPU#17 (0x12) not responding - cannot use it. <<-BOGUS
I don't quite understand how this works. The current code is clearly wrong, but if the AP in a 2-CPU system fails to start, won't the new code print "phys CPU#0 not responding"? That doesn't seem accurate.
If we really need this printk, it seems like the logical place to put it would be in do_boot_cpu(), where we already print the "Processor X/Y is stuck" message. 2.5 seems to have just removed the "not responding" printk, though, and I'd be inclined to do the same. Any objections?
Quoted 13 lines
arch/ia64/kernel/smpboot.c +1
-1@@ -522,7 +522,7 @@/* * Make sure we unmap all failed CPUs */ -if (ia64_cpu_to_sapicid[cpu] =-1 ) +if (ia64_cpu_to_sapicid[cpucount] =-1 )printk ("phys CPU#%d not responding - cannot use it.\n" , cpu); }
Quoted 11 lines · Bjorn Helgaas
Quoted 9 lines · Martin Hicks
This patch should be applied. I finally got around to doing some more testing with it. If a CPU fails to start, currently we get messages like the following for subsequent CPU's:
CPU 17: nasid 18, slice 0, cnode 9
CPU 17: base freq 0.000MHz, ITC ratio/2, ITC freq00.000MHz Calibrating delay loop... 1494.72 BogoMIPS
phys CPU#17 (0x12) not responding - cannot use it. <<-BOGUS
Quoted 8 lines
I don't quite understand how this works. The current code is clearly wrong, but if the AP in a 2-CPU system fails to start, won't the new code print "phys CPU#0 not responding"? That doesn't seem accurate.
If we really need this printk, it seems like the logical place to put it would be in
do_boot_cpu(), where we already print the "Processor X/Y is stuck" message. 2.5 seems to have just removed the "not responding" printk, though, and I'd be inclined to do the same. Any objections?
I have no objections.
mh
Signature · 1 line
Wild Open Source Inc. [email protected]