* [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-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-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 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: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: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 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: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
* 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 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: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 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: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 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 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
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.