* [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
@ 2009-08-24 18:26 Ravikiran G Thirumalai
2009-08-24 23:53 ` Yinghai Lu
0 siblings, 1 reply; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-24 18:26 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Yinghai Lu, torvalds, linux-kernel, shai
2.6.31-rc7 does not boot on vSMPowered systems. The sched domains
seem to build incorrectly with error messages of the sort:
[ 8.501108] CPU31: Thermal monitoring enabled (TM1)
[ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
[ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
stepping 04
[ 8.710324] Brought up 32 CPUs
[ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
[ 8.721489] ERROR: parent span is not a superset of domain->span
[ 8.727686] ERROR: domain->groups does not contain CPU0
[ 8.733091] ERROR: groups don't span domain->span
[ 8.737975] ERROR: domain->cpu_power not set
[ 8.742416]
This is followed by oopsen in the scheduler code
with NULL pointer deference in find_busiest_group.
Git bisection pointed to the following commit:
commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
x86: don't call read_apic_id if !cpu_has_apic
Upon examining the history of the commit, the above commit seems to be a fix
for:
commit 4797f6b021a3fa399942245d07a1feb30df81bb8
x86: read apic ID in the !acpi_lapic case
However, there appears to be bug in the commit
2759c3287de27266e06f1f4e82cbd2d65f6a044c, where flat_phys_pkg_id
uses initial apic id instead of hard_smp_processor_id() on SMP machines.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
This patch fixes the bug and causes vSMPowered systems to boot up
correctly,
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c
===================================================================
--- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700
+++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700
@@ -161,7 +161,8 @@ static int flat_apic_id_registered(void)
static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
{
- return initial_apic_id >> index_msb;
+ return cpu_has_apic ? hard_smp_processor_id() >> index_msb :
+ initial_apic_id >> index_msb;
}
struct apic apic_flat = {
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-24 18:26 [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai
@ 2009-08-24 23:53 ` Yinghai Lu
2009-08-25 0:27 ` Yinghai Lu
2009-08-25 1:26 ` Ravikiran G Thirumalai
0 siblings, 2 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-24 23:53 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: Ingo Molnar, torvalds, linux-kernel, shai
Ravikiran G Thirumalai wrote:
> 2.6.31-rc7 does not boot on vSMPowered systems. The sched domains
> seem to build incorrectly with error messages of the sort:
>
> [ 8.501108] CPU31: Thermal monitoring enabled (TM1)
> [ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
> [ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
> stepping 04
> [ 8.710324] Brought up 32 CPUs
> [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
> [ 8.721489] ERROR: parent span is not a superset of domain->span
> [ 8.727686] ERROR: domain->groups does not contain CPU0
> [ 8.733091] ERROR: groups don't span domain->span
> [ 8.737975] ERROR: domain->cpu_power not set
> [ 8.742416]
>
> This is followed by oopsen in the scheduler code
> with NULL pointer deference in find_busiest_group.
>
> Git bisection pointed to the following commit:
>
> commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
> x86: don't call read_apic_id if !cpu_has_apic
>
> Upon examining the history of the commit, the above commit seems to be a fix
> for:
>
> commit 4797f6b021a3fa399942245d07a1feb30df81bb8
> x86: read apic ID in the !acpi_lapic case
>
> However, there appears to be bug in the commit
> 2759c3287de27266e06f1f4e82cbd2d65f6a044c, where flat_phys_pkg_id
> uses initial apic id instead of hard_smp_processor_id() on SMP machines.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
>
> This patch fixes the bug and causes vSMPowered systems to boot up
> correctly,
>
> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
>
> Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c
> ===================================================================
> --- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700
> +++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700
> @@ -161,7 +161,8 @@ static int flat_apic_id_registered(void)
>
> static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
> {
> - return initial_apic_id >> index_msb;
> + return cpu_has_apic ? hard_smp_processor_id() >> index_msb :
> + initial_apic_id >> index_msb;
> }
it seems we should use initial apic id here.
can you check which calling for vsmp cause the problem?
arch/x86/kernel/cpu/addon_cpuid_features.c: c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, ht_mask_width)
arch/x86/kernel/cpu/addon_cpuid_features.c: c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, core_plus_mask_width
);
arch/x86/kernel/cpu/addon_cpuid_features.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
arch/x86/kernel/cpu/common.c: c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, index_msb);
arch/x86/kernel/cpu/common.c: c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, index_msb) &
arch/x86/kernel/cpu/common.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
arch/x86/kernel/cpu/common.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-24 23:53 ` Yinghai Lu
@ 2009-08-25 0:27 ` Yinghai Lu
2009-08-25 1:38 ` Ravikiran G Thirumalai
2009-08-25 1:26 ` Ravikiran G Thirumalai
1 sibling, 1 reply; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 0:27 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: Ingo Molnar, torvalds, linux-kernel, shai
Yinghai Lu wrote:
> Ravikiran G Thirumalai wrote:
>> 2.6.31-rc7 does not boot on vSMPowered systems. The sched domains
>> seem to build incorrectly with error messages of the sort:
>>
>> [ 8.501108] CPU31: Thermal monitoring enabled (TM1)
>> [ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
>> [ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
>> stepping 04
>> [ 8.710324] Brought up 32 CPUs
>> [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
>> [ 8.721489] ERROR: parent span is not a superset of domain->span
>> [ 8.727686] ERROR: domain->groups does not contain CPU0
>> [ 8.733091] ERROR: groups don't span domain->span
>> [ 8.737975] ERROR: domain->cpu_power not set
>> [ 8.742416]
>>
>> This is followed by oopsen in the scheduler code
>> with NULL pointer deference in find_busiest_group.
>>
>> Git bisection pointed to the following commit:
>>
>> commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
>> x86: don't call read_apic_id if !cpu_has_apic
>>
>> Upon examining the history of the commit, the above commit seems to be a fix
>> for:
>>
>> commit 4797f6b021a3fa399942245d07a1feb30df81bb8
>> x86: read apic ID in the !acpi_lapic case
>>
>> However, there appears to be bug in the commit
>> 2759c3287de27266e06f1f4e82cbd2d65f6a044c, where flat_phys_pkg_id
>> uses initial apic id instead of hard_smp_processor_id() on SMP machines.
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
>>
>> This patch fixes the bug and causes vSMPowered systems to boot up
>> correctly,
can you check if this one fix your problem?
BTW: what does your /proc/cpuinfo print about apic id and initial apic id?
[PATCH] x86: use read_apic_id to get apic id
and leave phys_proc_id to use initial apic id.
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -715,7 +715,7 @@ static void __cpuinit generic_identify(s
c->initial_apicid = (cpuid_ebx(1) >> 24) & 0xFF;
#ifdef CONFIG_X86_32
# ifdef CONFIG_X86_HT
- c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
+ c->apicid = read_apic_id();
# else
c->apicid = c->initial_apicid;
# endif
@@ -772,7 +772,7 @@ static void __cpuinit identify_cpu(struc
}
#ifdef CONFIG_X86_64
- c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
+ c->apicid = read_apic_id();
#endif
/*
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-24 23:53 ` Yinghai Lu
2009-08-25 0:27 ` Yinghai Lu
@ 2009-08-25 1:26 ` Ravikiran G Thirumalai
2009-08-25 5:12 ` Yinghai Lu
1 sibling, 1 reply; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 1:26 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Ingo Molnar, torvalds, linux-kernel, shai
On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
>Ravikiran G Thirumalai wrote:
>>
>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
>> Cc: Yinghai Lu <yinghai@kernel.org>
>>
>> Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c
>> ===================================================================
>> --- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700
>> +++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700
>> @@ -161,7 +161,8 @@ static int flat_apic_id_registered(void)
>>
>> static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
>> {
>> - return initial_apic_id >> index_msb;
>> + return cpu_has_apic ? hard_smp_processor_id() >> index_msb :
>> + initial_apic_id >> index_msb;
>> }
>
>it seems we should use initial apic id here.
>
Why? The specs seem to indicate otherwise unless I am mistaken --
Intel systems programming guide, Vol 3A Part1, chapter 7 section
7.5.5 - Identifying Logical Processors in a MP system:
<quote>
After the BIOS has completed the MP initialization protocol, each logical
processor can be uniquely identified by its local APIC ID. Software can
access these APIC IDs in either of the following ways
</quote>
phys_pkg_id() indicates that the logical package id is being looked up,
so local apic id should be used here no?
What am I missing?
>can you check which calling for vsmp cause the problem?
>arch/x86/kernel/cpu/addon_cpuid_features.c: c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, ht_mask_width)
>arch/x86/kernel/cpu/addon_cpuid_features.c: c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, core_plus_mask_width
>);
>arch/x86/kernel/cpu/addon_cpuid_features.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
The above are definitely problematic. Anyplace that uses phys_pkg_id to get
the unique pkg id of a logical processor will have problems.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 0:27 ` Yinghai Lu
@ 2009-08-25 1:38 ` Ravikiran G Thirumalai
2009-08-25 5:03 ` Yinghai Lu
0 siblings, 1 reply; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 1:38 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Ingo Molnar, torvalds, linux-kernel, shai
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Mon, Aug 24, 2009 at 05:27:03PM -0700, Yinghai Lu wrote:
>Yinghai Lu wrote:
>> Ravikiran G Thirumalai wrote:
>can you check if this one fix your problem?
>
Nope it doesn't :(
>BTW: what does your /proc/cpuinfo print about apic id and initial apic id?
>
Here's a sample cpuinfo from an older kernel (attached)
[-- Attachment #2: cpuinfo --]
[-- Type: text/plain, Size: 42736 bytes --]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5871.22
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5852.70
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5852.83
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5852.59
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 16
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5853.76
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 18
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5853.72
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 20
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5856.30
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 22
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5856.34
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 8
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 2
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 32
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5865.94
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 9
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 2
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 34
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.71
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 10
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 2
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 36
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 11
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 2
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 38
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.25
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 12
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 3
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 48
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.65
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 13
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 3
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 50
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 14
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 3
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 52
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.20
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 3
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 54
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.63
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 16
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 4
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 64
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.64
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 17
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 4
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 66
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.55
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 18
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 4
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 68
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.31
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 19
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 4
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 70
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.64
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 20
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 5
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 80
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.43
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 21
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 5
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 82
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.26
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 22
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 5
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 84
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.89
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 5
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 86
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.31
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 24
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 6
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 96
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.04
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 25
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 6
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 98
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.62
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 26
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 6
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 100
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5865.17
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 27
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 6
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 102
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5864.31
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 28
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 7
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 112
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.86
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 29
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 7
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 114
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.98
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 30
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 7
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 116
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.39
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 31
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 7
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 118
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.46
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 32
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 8
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 128
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.26
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 33
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 8
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 130
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.83
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 34
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 8
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 132
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.41
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 35
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 8
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 134
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.10
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 36
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 9
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 144
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.94
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 37
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 9
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 146
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.10
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 38
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 9
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 148
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.16
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 39
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 9
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 150
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.76
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 40
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 10
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 160
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.80
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 41
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 10
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 162
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.70
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 42
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 10
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 164
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.25
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 43
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 10
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 166
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.27
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 44
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 11
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 176
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.09
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 45
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 11
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 178
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.89
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 46
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 11
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 180
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5871.30
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 47
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 11
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 182
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.35
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 48
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 12
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 192
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.68
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 49
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 12
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 194
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.43
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 50
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 12
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 196
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5865.60
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 51
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 12
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 198
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.01
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 52
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 13
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 208
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.82
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 53
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 13
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 210
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.69
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 54
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 13
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 212
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5867.73
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 55
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 13
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 214
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5866.55
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 56
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 14
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 224
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5868.81
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 57
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 14
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 226
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.90
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 58
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 14
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 228
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.19
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 59
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 14
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 230
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.07
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 60
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 15
siblings : 4
core id : 0
cpu cores : 4
cpu cores : 4
apicid : 240
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5869.63
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 61
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 15
siblings : 4
core id : 1
cpu cores : 4
cpu cores : 4
apicid : 242
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.38
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 62
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 15
siblings : 4
core id : 2
cpu cores : 4
cpu cores : 4
apicid : 244
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.10
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
processor : 63
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2926.327
cache size : 8192 KB
physical id : 15
siblings : 4
core id : 3
cpu cores : 4
cpu cores : 4
apicid : 246
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx rdtscp lm constant_tsc pni ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5870.64
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 1:38 ` Ravikiran G Thirumalai
@ 2009-08-25 5:03 ` Yinghai Lu
0 siblings, 0 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 5:03 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: Ingo Molnar, torvalds, linux-kernel, shai
Ravikiran G Thirumalai wrote:
> On Mon, Aug 24, 2009 at 05:27:03PM -0700, Yinghai Lu wrote:
>> Yinghai Lu wrote:
>>> Ravikiran G Thirumalai wrote:
>> can you check if this one fix your problem?
>>
>
> Nope it doesn't :(
then there is other path
>
>
>> BTW: what does your /proc/cpuinfo print about apic id and initial apic id?
>>
>
> Here's a sample cpuinfo from an older kernel (attached)
>
>
why there is two lines cores?
also we should have initial apic id field...
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 1:26 ` Ravikiran G Thirumalai
@ 2009-08-25 5:12 ` Yinghai Lu
2009-08-25 17:17 ` Ravikiran G Thirumalai
0 siblings, 1 reply; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 5:12 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Ingo Molnar, torvalds, linux-kernel, shai, Suresh Siddha
Ravikiran G Thirumalai wrote:
> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
>> Ravikiran G Thirumalai wrote:
>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
>>> Cc: Yinghai Lu <yinghai@kernel.org>
>>>
>>> Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c
>>> ===================================================================
>>> --- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700
>>> +++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700
>>> @@ -161,7 +161,8 @@ static int flat_apic_id_registered(void)
>>>
>>> static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
>>> {
>>> - return initial_apic_id >> index_msb;
>>> + return cpu_has_apic ? hard_smp_processor_id() >> index_msb :
>>> + initial_apic_id >> index_msb;
>>> }
>> it seems we should use initial apic id here.
>>
>
> Why? The specs seem to indicate otherwise unless I am mistaken --
> Intel systems programming guide, Vol 3A Part1, chapter 7 section
> 7.5.5 - Identifying Logical Processors in a MP system:
> <quote>
> After the BIOS has completed the MP initialization protocol, each logical
> processor can be uniquely identified by its local APIC ID. Software can
> access these APIC IDs in either of the following ways
> </quote>
> phys_pkg_id() indicates that the logical package id is being looked up,
> so local apic id should be used here no?
> What am I missing?
initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
>
>
>> can you check which calling for vsmp cause the problem?
>> arch/x86/kernel/cpu/addon_cpuid_features.c: c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, ht_mask_width)
>> arch/x86/kernel/cpu/addon_cpuid_features.c: c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, core_plus_mask_width
>> );
>> arch/x86/kernel/cpu/addon_cpuid_features.c: c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
>
> The above are definitely problematic. Anyplace that uses phys_pkg_id to get
> the unique pkg id of a logical processor will have problems.
that is from intel new cpuid(0x0b) leaf, that is with initial_apicid according to intel EDS.
we need to figure out your initial apic id. and find out good way for phys_pkg_id.
and may need to modify apic->phys_pkg_id member according to dmi info.
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 5:12 ` Yinghai Lu
@ 2009-08-25 17:17 ` Ravikiran G Thirumalai
2009-08-25 18:15 ` Ingo Molnar
0 siblings, 1 reply; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 17:17 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Ingo Molnar, torvalds, linux-kernel, shai, Suresh Siddha
On Mon, Aug 24, 2009 at 10:12:01PM -0700, Yinghai Lu wrote:
>Ravikiran G Thirumalai wrote:
>> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
>>> Ravikiran G Thirumalai wrote:
>>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
>>>> Cc: Yinghai Lu <yinghai@kernel.org>
>>>>
>>>
>>
>> Why? The specs seem to indicate otherwise unless I am mistaken --
>> Intel systems programming guide, Vol 3A Part1, chapter 7 section
>> 7.5.5 - Identifying Logical Processors in a MP system:
>> <quote>
>> After the BIOS has completed the MP initialization protocol, each logical
>> processor can be uniquely identified by its local APIC ID. Software can
>> access these APIC IDs in either of the following ways
>> </quote>
>> phys_pkg_id() indicates that the logical package id is being looked up,
>> so local apic id should be used here no?
>> What am I missing?
>
>initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
>
>apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
>
But BIOS is supposed to change it to a sane value. Until 2.6.30, local apic
id has been used to get phys_pkg_id for the 'flat' apics! What changed? Was
this changed for a BIOS bug? Even the intel books seem to indicate local
apic usage!
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 17:17 ` Ravikiran G Thirumalai
@ 2009-08-25 18:15 ` Ingo Molnar
2009-08-25 18:31 ` Cyrill Gorcunov
2009-08-25 18:35 ` Yinghai Lu
0 siblings, 2 replies; 28+ messages in thread
From: Ingo Molnar @ 2009-08-25 18:15 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Yinghai Lu, torvalds, linux-kernel, shai, Suresh Siddha
* Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> On Mon, Aug 24, 2009 at 10:12:01PM -0700, Yinghai Lu wrote:
> >Ravikiran G Thirumalai wrote:
> >> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
> >>> Ravikiran G Thirumalai wrote:
> >>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> >>>> Cc: Yinghai Lu <yinghai@kernel.org>
> >>>>
> >>>
> >>
> >> Why? The specs seem to indicate otherwise unless I am mistaken --
> >> Intel systems programming guide, Vol 3A Part1, chapter 7 section
> >> 7.5.5 - Identifying Logical Processors in a MP system:
> >> <quote>
> >> After the BIOS has completed the MP initialization protocol, each logical
> >> processor can be uniquely identified by its local APIC ID. Software can
> >> access these APIC IDs in either of the following ways
> >> </quote>
> >> phys_pkg_id() indicates that the logical package id is being looked up,
> >> so local apic id should be used here no?
> >> What am I missing?
> >
> >initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
> >
> >apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
> >
>
> But BIOS is supposed to change it to a sane value. Until 2.6.30,
> local apic id has been used to get phys_pkg_id for the 'flat'
> apics! What changed? Was this changed for a BIOS bug? Even the
> intel books seem to indicate local apic usage!
We should revert to the .30 behavior unless there's a good reason
(even in that case we'll solve the regression and do a workaround
for vSMP). Yinghai?
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:15 ` Ingo Molnar
@ 2009-08-25 18:31 ` Cyrill Gorcunov
2009-08-25 18:50 ` Yinghai Lu
2009-08-25 19:20 ` Ravikiran G Thirumalai
2009-08-25 18:35 ` Yinghai Lu
1 sibling, 2 replies; 28+ messages in thread
From: Cyrill Gorcunov @ 2009-08-25 18:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ravikiran G Thirumalai, Yinghai Lu, torvalds, linux-kernel, shai,
Suresh Siddha
[Ingo Molnar - Tue, Aug 25, 2009 at 08:15:00PM +0200]
|
| * Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
|
| > On Mon, Aug 24, 2009 at 10:12:01PM -0700, Yinghai Lu wrote:
| > >Ravikiran G Thirumalai wrote:
| > >> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
| > >>> Ravikiran G Thirumalai wrote:
| > >>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
| > >>>> Cc: Yinghai Lu <yinghai@kernel.org>
| > >>>>
| > >>>
| > >>
| > >> Why? The specs seem to indicate otherwise unless I am mistaken --
| > >> Intel systems programming guide, Vol 3A Part1, chapter 7 section
| > >> 7.5.5 - Identifying Logical Processors in a MP system:
| > >> <quote>
| > >> After the BIOS has completed the MP initialization protocol, each logical
| > >> processor can be uniquely identified by its local APIC ID. Software can
| > >> access these APIC IDs in either of the following ways
| > >> </quote>
| > >> phys_pkg_id() indicates that the logical package id is being looked up,
| > >> so local apic id should be used here no?
| > >> What am I missing?
| > >
| > >initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
| > >
| > >apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
| > >
| >
| > But BIOS is supposed to change it to a sane value. Until 2.6.30,
| > local apic id has been used to get phys_pkg_id for the 'flat'
| > apics! What changed? Was this changed for a BIOS bug? Even the
| > intel books seem to indicate local apic usage!
|
| We should revert to the .30 behavior unless there's a good reason
| (even in that case we'll solve the regression and do a workaround
| for vSMP). Yinghai?
|
| Ingo
I'm definitely not APIC expert but since I was partially involved
letme turn in.
Original commit which causes problem for vSMP seems to be due
to cpu_has_apic bit turned off (ie due to being manually disabled
or acpi table broken) so further read apic id will return plain
zero (we're talking about 64 bits now). So frnakly I don't understand
what is wrong with Ravikiran's patch. In case of apic disabled
initial apic value will be used anyway (which is latched but
actually may be changed, but it's not our case).
Or perhaps there is an issue in srat numa nodes numbering?
-- Cyrill
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:15 ` Ingo Molnar
2009-08-25 18:31 ` Cyrill Gorcunov
@ 2009-08-25 18:35 ` Yinghai Lu
1 sibling, 0 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 18:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ravikiran G Thirumalai, torvalds, linux-kernel, shai, Suresh Siddha
Ingo Molnar wrote:
> * Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
>> On Mon, Aug 24, 2009 at 10:12:01PM -0700, Yinghai Lu wrote:
>>> Ravikiran G Thirumalai wrote:
>>>> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
>>>>> Ravikiran G Thirumalai wrote:
>>>>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
>>>>>> Cc: Yinghai Lu <yinghai@kernel.org>
>>>>>>
>>>> Why? The specs seem to indicate otherwise unless I am mistaken --
>>>> Intel systems programming guide, Vol 3A Part1, chapter 7 section
>>>> 7.5.5 - Identifying Logical Processors in a MP system:
>>>> <quote>
>>>> After the BIOS has completed the MP initialization protocol, each logical
>>>> processor can be uniquely identified by its local APIC ID. Software can
>>>> access these APIC IDs in either of the following ways
>>>> </quote>
>>>> phys_pkg_id() indicates that the logical package id is being looked up,
>>>> so local apic id should be used here no?
>>>> What am I missing?
>>> initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
>>>
>>> apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
>>>
>> But BIOS is supposed to change it to a sane value. Until 2.6.30,
>> local apic id has been used to get phys_pkg_id for the 'flat'
>> apics! What changed? Was this changed for a BIOS bug? Even the
>> intel books seem to indicate local apic usage!
>
> We should revert to the .30 behavior unless there's a good reason
> (even in that case we'll solve the regression and do a workaround
> for vSMP). Yinghai?
we should stop overloading phys_pkg_id to get physical processor id (socket id ?) and apic id.
we need to find out what vSMP initial apic id looks like. and have one better phys_pkg_id for it.
otherwise we have problem with intel system that have apic id changing by BIOS too.
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:31 ` Cyrill Gorcunov
@ 2009-08-25 18:50 ` Yinghai Lu
2009-08-25 18:57 ` Linus Torvalds
` (2 more replies)
2009-08-25 19:20 ` Ravikiran G Thirumalai
1 sibling, 3 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 18:50 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Ingo Molnar, Ravikiran G Thirumalai, torvalds, linux-kernel,
shai, Suresh Siddha
Cyrill Gorcunov wrote:
> [Ingo Molnar - Tue, Aug 25, 2009 at 08:15:00PM +0200]
> |
> | * Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> |
> | > On Mon, Aug 24, 2009 at 10:12:01PM -0700, Yinghai Lu wrote:
> | > >Ravikiran G Thirumalai wrote:
> | > >> On Mon, Aug 24, 2009 at 04:53:45PM -0700, Yinghai Lu wrote:
> | > >>> Ravikiran G Thirumalai wrote:
> | > >>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> | > >>>> Cc: Yinghai Lu <yinghai@kernel.org>
> | > >>>>
> | > >>>
> | > >>
> | > >> Why? The specs seem to indicate otherwise unless I am mistaken --
> | > >> Intel systems programming guide, Vol 3A Part1, chapter 7 section
> | > >> 7.5.5 - Identifying Logical Processors in a MP system:
> | > >> <quote>
> | > >> After the BIOS has completed the MP initialization protocol, each logical
> | > >> processor can be uniquely identified by its local APIC ID. Software can
> | > >> access these APIC IDs in either of the following ways
> | > >> </quote>
> | > >> phys_pkg_id() indicates that the logical package id is being looked up,
> | > >> so local apic id should be used here no?
> | > >> What am I missing?
> | > >
> | > >initial apic id : it can not changed, there is fixed mapping from that to physical processor id aka socket id / node id.
> | > >
> | > >apic id: could be changed by BIOS to any value. there is no good way to get phys_pkg_id from that.
> | > >
> | >
> | > But BIOS is supposed to change it to a sane value. Until 2.6.30,
> | > local apic id has been used to get phys_pkg_id for the 'flat'
> | > apics! What changed? Was this changed for a BIOS bug? Even the
> | > intel books seem to indicate local apic usage!
> |
> | We should revert to the .30 behavior unless there's a good reason
> | (even in that case we'll solve the regression and do a workaround
> | for vSMP). Yinghai?
> |
> | Ingo
>
> I'm definitely not APIC expert but since I was partially involved
> letme turn in.
>
> Original commit which causes problem for vSMP seems to be due
> to cpu_has_apic bit turned off (ie due to being manually disabled
> or acpi table broken) so further read apic id will return plain
> zero (we're talking about 64 bits now). So frnakly I don't understand
> what is wrong with Ravikiran's patch. In case of apic disabled
> initial apic value will be used anyway (which is latched but
> actually may be changed, but it's not our case).
initial apic id and apic id could be different.
and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:50 ` Yinghai Lu
@ 2009-08-25 18:57 ` Linus Torvalds
2009-08-25 19:12 ` Ingo Molnar
2009-08-25 18:59 ` Cyrill Gorcunov
2009-08-25 19:27 ` Ravikiran G Thirumalai
2 siblings, 1 reply; 28+ messages in thread
From: Linus Torvalds @ 2009-08-25 18:57 UTC (permalink / raw)
To: Yinghai Lu
Cc: Cyrill Gorcunov, Ingo Molnar, Ravikiran G Thirumalai,
linux-kernel, shai, Suresh Siddha
On Tue, 25 Aug 2009, Yinghai Lu wrote:
>
> initial apic id and apic id could be different.
>
> and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
Yinghai - I think you missed Cyrills' point. Let me repeat it:
"cpu_has_apic bit turned off"
there's no apic. No "initial apic id". No "phys pkg id". No nothing.
Discussions about "correct phys pkg id" are pointless.
Linus
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:50 ` Yinghai Lu
2009-08-25 18:57 ` Linus Torvalds
@ 2009-08-25 18:59 ` Cyrill Gorcunov
2009-08-25 19:27 ` Ravikiran G Thirumalai
2 siblings, 0 replies; 28+ messages in thread
From: Cyrill Gorcunov @ 2009-08-25 18:59 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Ravikiran G Thirumalai, torvalds, linux-kernel,
shai, Suresh Siddha
[Yinghai Lu - Tue, Aug 25, 2009 at 11:50:56AM -0700]
...
| > | We should revert to the .30 behavior unless there's a good reason
| > | (even in that case we'll solve the regression and do a workaround
| > | for vSMP). Yinghai?
| > |
| > | Ingo
| >
| > I'm definitely not APIC expert but since I was partially involved
| > letme turn in.
| >
| > Original commit which causes problem for vSMP seems to be due
| > to cpu_has_apic bit turned off (ie due to being manually disabled
| > or acpi table broken) so further read apic id will return plain
| > zero (we're talking about 64 bits now). So frnakly I don't understand
| > what is wrong with Ravikiran's patch. In case of apic disabled
| > initial apic value will be used anyway (which is latched but
| > actually may be changed, but it's not our case).
|
| initial apic id and apic id could be different.
yes, I know. initial one is latched by pins though still
could be changed (not always).
|
| and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
indeed, as function name implies. Need more code reading...
So (64 bits) at least generic_identify is not guilty since it uses initial
one from scratch. Need more code reading...
|
| YH
|
-- Cyrill
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:57 ` Linus Torvalds
@ 2009-08-25 19:12 ` Ingo Molnar
2009-08-25 19:17 ` Yinghai Lu
2009-08-25 19:53 ` [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai
0 siblings, 2 replies; 28+ messages in thread
From: Ingo Molnar @ 2009-08-25 19:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Yinghai Lu, Cyrill Gorcunov, Ravikiran G Thirumalai,
linux-kernel, shai, Suresh Siddha
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 25 Aug 2009, Yinghai Lu wrote:
> >
> > initial apic id and apic id could be different.
> >
> > and we should use initial apic id to get correct phys pkg id in
> > case BIOS set crazy apic id.
>
> Yinghai - I think you missed Cyrills' point. Let me repeat it:
>
> "cpu_has_apic bit turned off"
>
> there's no apic. No "initial apic id". No "phys pkg id". No
> nothing.
>
> Discussions about "correct phys pkg id" are pointless.
that's not the case here though:
[ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
so APICs are active. The real difference is i think this aspect of
commit 2759c3287:
static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
{
- return hard_smp_processor_id() >> index_msb;
+ return initial_apic_id >> index_msb;
}
We need to revert back to .30 behavior here. (In case of which
environment to trust we almost always trust whatever booted millions
of Linux boxes in the past already.)
Furthermore, commit 2759c3287 did not declare any side-effects and
clearly causes a side-effect on vSMP which apparently has an
overlapping set of initial APIC ids.
Ravikiran, your patch does not do a clear revert of this bit though.
If you do a plain revert of the line above alone, does that fix the
problem too?
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:12 ` Ingo Molnar
@ 2009-08-25 19:17 ` Yinghai Lu
2009-08-25 19:24 ` Ingo Molnar
2009-08-25 19:53 ` [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai
1 sibling, 1 reply; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 19:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Cyrill Gorcunov, Ravikiran G Thirumalai,
linux-kernel, shai, Suresh Siddha
Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> On Tue, 25 Aug 2009, Yinghai Lu wrote:
>>> initial apic id and apic id could be different.
>>>
>>> and we should use initial apic id to get correct phys pkg id in
>>> case BIOS set crazy apic id.
>> Yinghai - I think you missed Cyrills' point. Let me repeat it:
>>
>> "cpu_has_apic bit turned off"
>>
>> there's no apic. No "initial apic id". No "phys pkg id". No
>> nothing.
>>
>> Discussions about "correct phys pkg id" are pointless.
>
> that's not the case here though:
>
> [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
>
> so APICs are active. The real difference is i think this aspect of
> commit 2759c3287:
>
> static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
> {
> - return hard_smp_processor_id() >> index_msb;
> + return initial_apic_id >> index_msb;
> }
>
> We need to revert back to .30 behavior here. (In case of which
> environment to trust we almost always trust whatever booted millions
> of Linux boxes in the past already.)
>
> Furthermore, commit 2759c3287 did not declare any side-effects and
> clearly causes a side-effect on vSMP which apparently has an
> overlapping set of initial APIC ids.
>
> Ravikiran, your patch does not do a clear revert of this bit though.
> If you do a plain revert of the line above alone, does that fix the
> problem too?
how about patch phys_pkg_id for vsmp?
diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
index f3b1037..65edc18 100644
--- a/arch/x86/kernel/apic/probe_64.c
+++ b/arch/x86/kernel/apic/probe_64.c
@@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initdata = {
NULL,
};
+static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
+{
+ return hard_smp_processor_id() >> index_msb;
+}
+
/*
* Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
*/
@@ -69,6 +74,11 @@ void __init default_setup_apic_routing(void)
printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
}
+ if (is_vsmp_box()) {
+ /* need to update phys_pkg_id */
+ apic->phys_pkg_id = apicid_phys_pkg_id;
+ }
+
/*
* Now that apic routing model is selected, configure the
* fault handling for intr remapping.
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:31 ` Cyrill Gorcunov
2009-08-25 18:50 ` Yinghai Lu
@ 2009-08-25 19:20 ` Ravikiran G Thirumalai
2009-08-25 19:26 ` Ingo Molnar
2009-08-25 19:40 ` Cyrill Gorcunov
1 sibling, 2 replies; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 19:20 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Ingo Molnar, Yinghai Lu, torvalds, linux-kernel, shai, Suresh Siddha
On Tue, Aug 25, 2009 at 10:31:30PM +0400, Cyrill Gorcunov wrote:
>[Ingo Molnar - Tue, Aug 25, 2009 at 08:15:00PM +0200]
>|
>
>I'm definitely not APIC expert but since I was partially involved
>letme turn in.
>
>Original commit which causes problem for vSMP seems to be due
>to cpu_has_apic bit turned off (ie due to being manually disabled
>or acpi table broken) so further read apic id will return plain
>zero (we're talking about 64 bits now). So frnakly I don't understand
>what is wrong with Ravikiran's patch. In case of apic disabled
>initial apic value will be used anyway (which is latched but
>actually may be changed, but it's not our case).
>
Exactly my thinking. I hoped the patch I posted solves both cases --
does not depend on local apic id for the "fix crash on certain UP configs"
case in the commit here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
And fixes vsmp too.
>Or perhaps there is an issue in srat numa nodes numbering?
>
Don't think so, local apic id has been used for for 'flat' and 'cluster'
apic (which was used prior to 'flat') for atleast 15 major releases.
Cyrill/Yinghai, can you test and confirm if the patch attached does not
regress the 'UP crash case' mentioned in
commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c please?
---
2.6.31-rc7 does not boot on vSMPowered systems. The sched domains
seem to build incorrectly with error messages of the sort:
[ 8.501108] CPU31: Thermal monitoring enabled (TM1)
[ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
[ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
stepping 04
[ 8.710324] Brought up 32 CPUs
[ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
[ 8.721489] ERROR: parent span is not a superset of domain->span
[ 8.727686] ERROR: domain->groups does not contain CPU0
[ 8.733091] ERROR: groups don't span domain->span
[ 8.737975] ERROR: domain->cpu_power not set
[ 8.742416]
This is followed by oopsen in the scheduler code
with NULL pointer deference in find_busiest_group.
Git bisection pointed to the following commit:
commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
x86: don't call read_apic_id if !cpu_has_apic
Upon examining the history of the commit, the above commit seems to be a fix
for:
commit 4797f6b021a3fa399942245d07a1feb30df81bb8
x86: read apic ID in the !acpi_lapic case
However, there appears to be bug in the commit
2759c3287de27266e06f1f4e82cbd2d65f6a044c, where flat_phys_pkg_id
uses initial apic id instead of hard_smp_processor_id() on SMP machines.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
This patch fixes the bug and causes vSMPowered systems to boot up
correctly,
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Index: linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c
===================================================================
--- linux-2.6.31-rc6.orig/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 12:42:16.000000000 -0700
+++ linux-2.6.31-rc6/arch/x86/kernel/apic/apic_flat_64.c 2009-08-21 14:12:21.654837472 -0700
@@ -161,7 +161,8 @@ static int flat_apic_id_registered(void)
static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
{
- return initial_apic_id >> index_msb;
+ return cpu_has_apic ? hard_smp_processor_id() >> index_msb :
+ initial_apic_id >> index_msb;
}
struct apic apic_flat = {
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:17 ` Yinghai Lu
@ 2009-08-25 19:24 ` Ingo Molnar
2009-08-25 20:36 ` Ravikiran G Thirumalai
0 siblings, 1 reply; 28+ messages in thread
From: Ingo Molnar @ 2009-08-25 19:24 UTC (permalink / raw)
To: Yinghai Lu
Cc: Linus Torvalds, Cyrill Gorcunov, Ravikiran G Thirumalai,
linux-kernel, shai, Suresh Siddha
* Yinghai Lu <yinghai@kernel.org> wrote:
> Ingo Molnar wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> On Tue, 25 Aug 2009, Yinghai Lu wrote:
> >>> initial apic id and apic id could be different.
> >>>
> >>> and we should use initial apic id to get correct phys pkg id in
> >>> case BIOS set crazy apic id.
> >> Yinghai - I think you missed Cyrills' point. Let me repeat it:
> >>
> >> "cpu_has_apic bit turned off"
> >>
> >> there's no apic. No "initial apic id". No "phys pkg id". No
> >> nothing.
> >>
> >> Discussions about "correct phys pkg id" are pointless.
> >
> > that's not the case here though:
> >
> > [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
> >
> > so APICs are active. The real difference is i think this aspect of
> > commit 2759c3287:
> >
> > static int flat_phys_pkg_id(int initial_apic_id, int index_msb)
> > {
> > - return hard_smp_processor_id() >> index_msb;
> > + return initial_apic_id >> index_msb;
> > }
> >
> > We need to revert back to .30 behavior here. (In case of which
> > environment to trust we almost always trust whatever booted millions
> > of Linux boxes in the past already.)
> >
> > Furthermore, commit 2759c3287 did not declare any side-effects and
> > clearly causes a side-effect on vSMP which apparently has an
> > overlapping set of initial APIC ids.
> >
> > Ravikiran, your patch does not do a clear revert of this bit though.
> > If you do a plain revert of the line above alone, does that fix the
> > problem too?
>
> how about patch phys_pkg_id for vsmp?
>
> diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
> index f3b1037..65edc18 100644
> --- a/arch/x86/kernel/apic/probe_64.c
> +++ b/arch/x86/kernel/apic/probe_64.c
> @@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initdata = {
> NULL,
> };
>
> +static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
> +{
> + return hard_smp_processor_id() >> index_msb;
> +}
> +
> /*
> * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
> */
> @@ -69,6 +74,11 @@ void __init default_setup_apic_routing(void)
> printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
> }
>
> + if (is_vsmp_box()) {
> + /* need to update phys_pkg_id */
> + apic->phys_pkg_id = apicid_phys_pkg_id;
> + }
Hm, this is rather tempting simply because it only affects vSMP
systems and we are in late -rc's. Ravikiran, does Yinghai's patch
solve the crash for you too?
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:20 ` Ravikiran G Thirumalai
@ 2009-08-25 19:26 ` Ingo Molnar
2009-08-25 19:40 ` Cyrill Gorcunov
1 sibling, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2009-08-25 19:26 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Cyrill Gorcunov, Yinghai Lu, torvalds, linux-kernel, shai, Suresh Siddha
* Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> On Tue, Aug 25, 2009 at 10:31:30PM +0400, Cyrill Gorcunov wrote:
> >[Ingo Molnar - Tue, Aug 25, 2009 at 08:15:00PM +0200]
> >|
> >
> >I'm definitely not APIC expert but since I was partially involved
> >letme turn in.
> >
> >Original commit which causes problem for vSMP seems to be due
> >to cpu_has_apic bit turned off (ie due to being manually disabled
> >or acpi table broken) so further read apic id will return plain
> >zero (we're talking about 64 bits now). So frnakly I don't understand
> >what is wrong with Ravikiran's patch. In case of apic disabled
> >initial apic value will be used anyway (which is latched but
> >actually may be changed, but it's not our case).
> >
>
> Exactly my thinking. I hoped the patch I posted solves both cases --
> does not depend on local apic id for the "fix crash on certain UP configs"
> case in the commit here:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
>
> And fixes vsmp too.
Sidenote for .32: i am somewhat worried about the spreading of
various cpu_has_apic checks. We should separate it out more cleanly
and provide an apic-> callback instead and avoid this ugly flaggery.
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 18:50 ` Yinghai Lu
2009-08-25 18:57 ` Linus Torvalds
2009-08-25 18:59 ` Cyrill Gorcunov
@ 2009-08-25 19:27 ` Ravikiran G Thirumalai
2009-08-25 19:33 ` Ingo Molnar
2009-08-25 19:36 ` Yinghai Lu
2 siblings, 2 replies; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 19:27 UTC (permalink / raw)
To: Yinghai Lu
Cc: Cyrill Gorcunov, Ingo Molnar, torvalds, linux-kernel, shai,
Suresh Siddha
On Tue, Aug 25, 2009 at 11:50:56AM -0700, Yinghai Lu wrote:
>Cyrill Gorcunov wrote:
>
>initial apic id and apic id could be different.
>
>and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
>
Is there a specific bug we are fixing here? Again, this behavior was
present from atleast 2.6.15-2.6.30 on 'flat' and older 'cluster' apics, and intel
documentation suggests local apic be used. Is there a specific bios bug
that is being fixed?
(The BIOS is not supposed to set a crazy apic ID. The BIOS is buggy in that
case -- Quoting section 9.4.6 from Intel System programming guide vol 3A
part 1:
<quote>
9.4.6 Local APIC ID
At power up, system hardware assigns a unique APIC ID to each local APIC on
the system bus (for Pentium 4 and Intel Xeon processors) or on the APIC bus
(for P6 family and Pentium processors). The hardware assigned APIC ID is
based on system topology and includes encoding for socket position and
cluster information (see Figure 7-2).
In MP systems, the local APIC ID is also used as a processor ID by the BIOS
and the operating system....
</quote>)
Thanks,
Kiran
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:27 ` Ravikiran G Thirumalai
@ 2009-08-25 19:33 ` Ingo Molnar
2009-08-25 19:36 ` Yinghai Lu
1 sibling, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2009-08-25 19:33 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Yinghai Lu, Cyrill Gorcunov, torvalds, linux-kernel, shai, Suresh Siddha
* Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> On Tue, Aug 25, 2009 at 11:50:56AM -0700, Yinghai Lu wrote:
> >Cyrill Gorcunov wrote:
> >
> >initial apic id and apic id could be different.
> >
> >and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
> >
>
> Is there a specific bug we are fixing here? Again, this behavior
> was present from atleast 2.6.15-2.6.30 on 'flat' and older
> 'cluster' apics, and intel documentation suggests local apic be
> used. Is there a specific bios bug that is being fixed?
>
> (The BIOS is not supposed to set a crazy apic ID. The BIOS is
> buggy in that case -- Quoting section 9.4.6 from Intel System
> programming guide vol 3A part 1:
That means very little. If Yinghai fixed a real bug in an existing
system we should consider it. Yinghai?
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:27 ` Ravikiran G Thirumalai
2009-08-25 19:33 ` Ingo Molnar
@ 2009-08-25 19:36 ` Yinghai Lu
1 sibling, 0 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 19:36 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Cyrill Gorcunov, Ingo Molnar, torvalds, linux-kernel, shai,
Suresh Siddha
Ravikiran G Thirumalai wrote:
> On Tue, Aug 25, 2009 at 11:50:56AM -0700, Yinghai Lu wrote:
>> Cyrill Gorcunov wrote:
>>
>> initial apic id and apic id could be different.
>>
>> and we should use initial apic id to get correct phys pkg id in case BIOS set crazy apic id.
>>
>
> Is there a specific bug we are fixing here? Again, this behavior was
> present from atleast 2.6.15-2.6.30 on 'flat' and older 'cluster' apics, and intel
> documentation suggests local apic be used. Is there a specific bios bug
> that is being fixed?
>
> (The BIOS is not supposed to set a crazy apic ID. The BIOS is buggy in that
we can not stop BIOS doing crazy thing.
for AMD 8 socket 4 cores system. BSP apic id : 4 or 8, and initial apic id is 0:
with apic id in phys_pkg_id, will get pkg id: 1, 2, ...
with initial apic id will get pkg id: 0, 1, 2, 3.
when I was working on LinuxBIOS, I did have one porting to have
BSP: 0
AP: start from 5, 6, 7...
that will have strange in pkg_id.
YH
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:20 ` Ravikiran G Thirumalai
2009-08-25 19:26 ` Ingo Molnar
@ 2009-08-25 19:40 ` Cyrill Gorcunov
1 sibling, 0 replies; 28+ messages in thread
From: Cyrill Gorcunov @ 2009-08-25 19:40 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Ingo Molnar, Yinghai Lu, torvalds, linux-kernel, shai, Suresh Siddha
[Ravikiran G Thirumalai - Tue, Aug 25, 2009 at 12:20:55PM -0700]
| On Tue, Aug 25, 2009 at 10:31:30PM +0400, Cyrill Gorcunov wrote:
| >[Ingo Molnar - Tue, Aug 25, 2009 at 08:15:00PM +0200]
| >|
| >
| >I'm definitely not APIC expert but since I was partially involved
| >letme turn in.
| >
| >Original commit which causes problem for vSMP seems to be due
| >to cpu_has_apic bit turned off (ie due to being manually disabled
| >or acpi table broken) so further read apic id will return plain
| >zero (we're talking about 64 bits now). So frnakly I don't understand
| >what is wrong with Ravikiran's patch. In case of apic disabled
| >initial apic value will be used anyway (which is latched but
| >actually may be changed, but it's not our case).
| >
|
| Exactly my thinking. I hoped the patch I posted solves both cases --
| does not depend on local apic id for the "fix crash on certain UP configs"
| case in the commit here:
|
| http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2759c3287de27266e06f1f4e82cbd2d65f6a044c
|
| And fixes vsmp too.
|
| >Or perhaps there is an issue in srat numa nodes numbering?
| >
|
| Don't think so, local apic id has been used for for 'flat' and 'cluster'
| apic (which was used prior to 'flat') for atleast 15 major releases.
|
| Cyrill/Yinghai, can you test and confirm if the patch attached does not
| regress the 'UP crash case' mentioned in
| commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c please?
|
| ---
|
I would like to but I can;t. I don;t even know where were we hanging
at this crash case. I was only reading commit changelog and since
it was said about "not apic bit set" I thought about disabled apic case.
Personally I like much more quirk Yinghai posted which leaves phys id function
_bared_ and simple as it should be :)
And since it's too late before kernel release -- introducing read apic back
seems to be dangerous I suppose: there are a number of configs which could
be having side effect. At moment they are tested _with_ Yinghai patch and
only vSMP is issued. Though the problem need to be investigated more
closely. But I'm not knowing that much in this area.
-- Cyrill
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:12 ` Ingo Molnar
2009-08-25 19:17 ` Yinghai Lu
@ 2009-08-25 19:53 ` Ravikiran G Thirumalai
1 sibling, 0 replies; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 19:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Yinghai Lu, Cyrill Gorcunov, linux-kernel, shai,
Suresh Siddha
On Tue, Aug 25, 2009 at 09:12:31PM +0200, Ingo Molnar wrote:
>
>* Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
>Furthermore, commit 2759c3287 did not declare any side-effects and
>clearly causes a side-effect on vSMP which apparently has an
>overlapping set of initial APIC ids.
>
>Ravikiran, your patch does not do a clear revert of this bit though.
>If you do a plain revert of the line above alone, does that fix the
>problem too?
>
Yes it does. However, it probably reads local apic id when it shouldn't.
I am right now trying out the other patch Yinghai posted (based on
is_vsmp_box()), and report results in a few.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id
2009-08-25 19:24 ` Ingo Molnar
@ 2009-08-25 20:36 ` Ravikiran G Thirumalai
2009-08-25 20:44 ` [PATCH] x86: fix vsmp booting with phys_pkg_id changing Yinghai Lu
0 siblings, 1 reply; 28+ messages in thread
From: Ravikiran G Thirumalai @ 2009-08-25 20:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Yinghai Lu, Linus Torvalds, Cyrill Gorcunov, linux-kernel, shai,
Suresh Siddha
On Tue, Aug 25, 2009 at 09:24:16PM +0200, Ingo Molnar wrote:
>> ...
>> > Furthermore, commit 2759c3287 did not declare any side-effects and
>> > clearly causes a side-effect on vSMP which apparently has an
>> > overlapping set of initial APIC ids.
>> >
>> > Ravikiran, your patch does not do a clear revert of this bit though.
>> > If you do a plain revert of the line above alone, does that fix the
>> > problem too?
>>
>> how about patch phys_pkg_id for vsmp?
>>
>> diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
>> index f3b1037..65edc18 100644
>> --- a/arch/x86/kernel/apic/probe_64.c
>> +++ b/arch/x86/kernel/apic/probe_64.c
>> @@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initdata = {
>> NULL,
>> };
>>
>> +static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
>> +{
>> + return hard_smp_processor_id() >> index_msb;
>> +}
>> +
>> /*
>> * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
>> */
>> @@ -69,6 +74,11 @@ void __init default_setup_apic_routing(void)
>> printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
>> }
>>
>> + if (is_vsmp_box()) {
>> + /* need to update phys_pkg_id */
>> + apic->phys_pkg_id = apicid_phys_pkg_id;
>> + }
>
>Hm, this is rather tempting simply because it only affects vSMP
>systems and we are in late -rc's. Ravikiran, does Yinghai's patch
>solve the crash for you too?
>
Yes it does. Tested and confirmed.
Thanks,
Kiran
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH] x86: fix vsmp booting with phys_pkg_id changing
2009-08-25 20:36 ` Ravikiran G Thirumalai
@ 2009-08-25 20:44 ` Yinghai Lu
2009-08-26 8:08 ` Ingo Molnar
2009-08-26 8:15 ` [tip:x86/urgent] x86: Fix vSMP boot crash tip-bot for Yinghai Lu
0 siblings, 2 replies; 28+ messages in thread
From: Yinghai Lu @ 2009-08-25 20:44 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner
Cc: Ravikiran G Thirumalai, Linus Torvalds, Cyrill Gorcunov,
linux-kernel, shai, Suresh Siddha
2.6.31-rc7 does not boot on vSMPowered systems.
[ 8.501108] CPU31: Thermal monitoring enabled (TM1)
[ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
[ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping 04
[ 8.710324] Brought up 32 CPUs
[ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
[ 8.721489] ERROR: parent span is not a superset of domain->span
[ 8.727686] ERROR: domain->groups does not contain CPU0
[ 8.733091] ERROR: groups don't span domain->span
[ 8.737975] ERROR: domain->cpu_power not set
[ 8.742416]
bisected to
|
| commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
| x86: don't call read_apic_id if !cpu_has_apic
|
need to use apic id in phys_pkg_id for vsmp...
Reported-and-Tested-by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/apic/probe_64.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: linux-2.6/arch/x86/kernel/apic/probe_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/apic/probe_64.c
+++ linux-2.6/arch/x86/kernel/apic/probe_64.c
@@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initd
NULL,
};
+static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
+{
+ return hard_smp_processor_id() >> index_msb;
+}
+
/*
* Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
*/
@@ -69,6 +74,11 @@ void __init default_setup_apic_routing(v
printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
}
+ if (is_vsmp_box()) {
+ /* need to update phys_pkg_id */
+ apic->phys_pkg_id = apicid_phys_pkg_id;
+ }
+
/*
* Now that apic routing model is selected, configure the
* fault handling for intr remapping.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] x86: fix vsmp booting with phys_pkg_id changing
2009-08-25 20:44 ` [PATCH] x86: fix vsmp booting with phys_pkg_id changing Yinghai Lu
@ 2009-08-26 8:08 ` Ingo Molnar
2009-08-26 8:15 ` [tip:x86/urgent] x86: Fix vSMP boot crash tip-bot for Yinghai Lu
1 sibling, 0 replies; 28+ messages in thread
From: Ingo Molnar @ 2009-08-26 8:08 UTC (permalink / raw)
To: Yinghai Lu
Cc: Thomas Gleixner, Ravikiran G Thirumalai, Linus Torvalds,
Cyrill Gorcunov, linux-kernel, shai, Suresh Siddha
* Yinghai Lu <yinghai@kernel.org> wrote:
> 2.6.31-rc7 does not boot on vSMPowered systems.
>
> [ 8.501108] CPU31: Thermal monitoring enabled (TM1)
> [ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
> [ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping 04
> [ 8.710324] Brought up 32 CPUs
> [ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
> [ 8.721489] ERROR: parent span is not a superset of domain->span
> [ 8.727686] ERROR: domain->groups does not contain CPU0
> [ 8.733091] ERROR: groups don't span domain->span
> [ 8.737975] ERROR: domain->cpu_power not set
> [ 8.742416]
>
> bisected to
> |
> | commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
> | x86: don't call read_apic_id if !cpu_has_apic
> |
>
> need to use apic id in phys_pkg_id for vsmp...
>
> Reported-and-Tested-by: Ravikiran Thirumalai <kiran@scalex86.org>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> ---
> arch/x86/kernel/apic/probe_64.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> Index: linux-2.6/arch/x86/kernel/apic/probe_64.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/apic/probe_64.c
> +++ linux-2.6/arch/x86/kernel/apic/probe_64.c
> @@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initd
> NULL,
> };
>
> +static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
> +{
> + return hard_smp_processor_id() >> index_msb;
> +}
> +
> /*
> * Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
> */
> @@ -69,6 +74,11 @@ void __init default_setup_apic_routing(v
> printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
> }
>
> + if (is_vsmp_box()) {
> + /* need to update phys_pkg_id */
> + apic->phys_pkg_id = apicid_phys_pkg_id;
> + }
Ok, this looks like a rather straightforward quirk - and vSMP is
indeed special in that it sets up overlapping APIC ids. It's also
the smaller patch with basically zero cross section to other
systems, so a lot more -rc7 worthy.
So i've applied it to x86/urgent (with small edits to the
changelog). Any objections from anyone?
Note, should any other, real hardware show problems with , we might
still have to consider reverting the original change in 2759c32.
It's borderline.
Btw., the code is still not fully clean. For example this bit in
generic_identify():
#ifdef CONFIG_X86_32
# ifdef CONFIG_X86_HT
c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
# else
c->apicid = c->initial_apicid;
# endif
#endif
and in another place we have:
#ifdef CONFIG_X86_64
c->apicid = apic->phys_pkg_id(c->initial_apicid, 0);
#endif
This ifdeffery could probably be removed and we could call
->phys_pkg_id() all the time, right?
Ingo
^ permalink raw reply [flat|nested] 28+ messages in thread
* [tip:x86/urgent] x86: Fix vSMP boot crash
2009-08-25 20:44 ` [PATCH] x86: fix vsmp booting with phys_pkg_id changing Yinghai Lu
2009-08-26 8:08 ` Ingo Molnar
@ 2009-08-26 8:15 ` tip-bot for Yinghai Lu
1 sibling, 0 replies; 28+ messages in thread
From: tip-bot for Yinghai Lu @ 2009-08-26 8:15 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, torvalds, shai, gorcunov,
kiran, suresh.b.siddha, tglx, mingo
Commit-ID: 295594e9cf6ae2efd73371777aa8feba0f87f42f
Gitweb: http://git.kernel.org/tip/295594e9cf6ae2efd73371777aa8feba0f87f42f
Author: Yinghai Lu <yinghai@kernel.org>
AuthorDate: Tue, 25 Aug 2009 13:44:44 -0700
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Wed, 26 Aug 2009 10:13:17 +0200
x86: Fix vSMP boot crash
2.6.31-rc7 does not boot on vSMP systems:
[ 8.501108] CPU31: Thermal monitoring enabled (TM1)
[ 8.501127] CPU 31 MCA banks SHD:2 SHD:3 SHD:5 SHD:6 SHD:8
[ 8.650254] CPU31: Intel(R) Xeon(R) CPU E5540 @ 2.53GHz stepping 04
[ 8.710324] Brought up 32 CPUs
[ 8.713916] Total of 32 processors activated (162314.96 BogoMIPS).
[ 8.721489] ERROR: parent span is not a superset of domain->span
[ 8.727686] ERROR: domain->groups does not contain CPU0
[ 8.733091] ERROR: groups don't span domain->span
[ 8.737975] ERROR: domain->cpu_power not set
[ 8.742416]
Ravikiran Thirumalai bisected it to:
| commit 2759c3287de27266e06f1f4e82cbd2d65f6a044c
| x86: don't call read_apic_id if !cpu_has_apic
The problem is that on vSMP systems the CPUID derived
initial-APICIDs are overlapping - so we need to fall
back on hard_smp_processor_id() which reads the local
APIC.
Both come from the hardware (influenced by firmware
though) so it's a tough call which one to trust.
Doing the quirk expresses the vSMP property properly
and also does not affect other systems, so we go for
this solution instead of a revert.
Reported-and-Tested-by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Shai Fultheim <shai@scalex86.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <4A944D3C.5030100@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/apic/probe_64.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
index bc3e880..fcec2f1 100644
--- a/arch/x86/kernel/apic/probe_64.c
+++ b/arch/x86/kernel/apic/probe_64.c
@@ -44,6 +44,11 @@ static struct apic *apic_probe[] __initdata = {
NULL,
};
+static int apicid_phys_pkg_id(int initial_apic_id, int index_msb)
+{
+ return hard_smp_processor_id() >> index_msb;
+}
+
/*
* Check the APIC IDs in bios_cpu_apicid and choose the APIC mode.
*/
@@ -69,6 +74,11 @@ void __init default_setup_apic_routing(void)
printk(KERN_INFO "Setting APIC routing to %s\n", apic->name);
}
+ if (is_vsmp_box()) {
+ /* need to update phys_pkg_id */
+ apic->phys_pkg_id = apicid_phys_pkg_id;
+ }
+
/*
* Now that apic routing model is selected, configure the
* fault handling for intr remapping.
^ permalink raw reply related [flat|nested] 28+ messages in thread
end of thread, other threads:[~2009-08-26 8:16 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-24 18:26 [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai
2009-08-24 23:53 ` Yinghai Lu
2009-08-25 0:27 ` Yinghai Lu
2009-08-25 1:38 ` Ravikiran G Thirumalai
2009-08-25 5:03 ` Yinghai Lu
2009-08-25 1:26 ` Ravikiran G Thirumalai
2009-08-25 5:12 ` Yinghai Lu
2009-08-25 17:17 ` Ravikiran G Thirumalai
2009-08-25 18:15 ` Ingo Molnar
2009-08-25 18:31 ` Cyrill Gorcunov
2009-08-25 18:50 ` Yinghai Lu
2009-08-25 18:57 ` Linus Torvalds
2009-08-25 19:12 ` Ingo Molnar
2009-08-25 19:17 ` Yinghai Lu
2009-08-25 19:24 ` Ingo Molnar
2009-08-25 20:36 ` Ravikiran G Thirumalai
2009-08-25 20:44 ` [PATCH] x86: fix vsmp booting with phys_pkg_id changing Yinghai Lu
2009-08-26 8:08 ` Ingo Molnar
2009-08-26 8:15 ` [tip:x86/urgent] x86: Fix vSMP boot crash tip-bot for Yinghai Lu
2009-08-25 19:53 ` [patch] x86: 2.6.31-rc7 crash due to buggy flat_phys_pkg_id Ravikiran G Thirumalai
2009-08-25 18:59 ` Cyrill Gorcunov
2009-08-25 19:27 ` Ravikiran G Thirumalai
2009-08-25 19:33 ` Ingo Molnar
2009-08-25 19:36 ` Yinghai Lu
2009-08-25 19:20 ` Ravikiran G Thirumalai
2009-08-25 19:26 ` Ingo Molnar
2009-08-25 19:40 ` Cyrill Gorcunov
2009-08-25 18:35 ` Yinghai Lu
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.