Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 10:42 AM, Ravikiran Thirumalai <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: > >On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> > wrote: > >> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: > >> > >> > > > >> >If you can't support that in your hardware you're supposed > >> >to clear it. > >> > >> Hmm! How would a hardware vendor do that? That doesn't seem to be clear > in > >> the BKDG. (Well, this is the problem with undocumented features :() > >> > >any good sign for APIC_clustered box? there is apicid between cpus > >even all cpu are quadcore and fully populated? > > I would suggest checking the SLIT distances -- On AMD boxes, if you have > three > different distances between nodes, then that system would be multiboard, > and there is no way TSCs can be synced. On Intel boxes, if there are two > different distances between nodes, then this would be a multi board/multi > chassi box and TSCs won't be synced. This is a more generic solution and > should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for > now. It might need the same treatment as AMD) 1. if acpi=off ? 2. some system will be treated wrong. my four sockets system ACPI: SLIT: nodes = 4 10 13 13 16 13 10 16 13 13 16 10 13 16 13 13 10 my eight sockets system ACPI: SLIT: nodes = 8 10 12 12 14 14 14 14 16 12 10 14 12 14 14 12 14 12 14 10 14 12 12 14 14 14 12 14 10 12 12 14 14 14 14 12 12 10 14 12 14 14 14 12 12 14 10 14 12 14 12 14 14 12 14 10 12 16 14 14 14 14 12 12 10 YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: >On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> >wrote: >> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: >> >> > >> >If you can't support that in your hardware you're supposed >> >to clear it. >> >> Hmm! How would a hardware vendor do that? That doesn't seem to be clear in >> the BKDG. (Well, this is the problem with undocumented features :() >> >any good sign for APIC_clustered box? there is apicid between cpus >even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) Comments? Kiran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) Comments? Kiran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 10:42 AM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 09:27:42PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? I would suggest checking the SLIT distances -- On AMD boxes, if you have three different distances between nodes, then that system would be multiboard, and there is no way TSCs can be synced. On Intel boxes, if there are two different distances between nodes, then this would be a multi board/multi chassi box and TSCs won't be synced. This is a more generic solution and should work on Summit/Unisys boxes as well. (I am ignoring Intel CSI for now. It might need the same treatment as AMD) 1. if acpi=off ? 2. some system will be treated wrong. my four sockets system ACPI: SLIT: nodes = 4 10 13 13 16 13 10 16 13 13 16 10 13 16 13 13 10 my eight sockets system ACPI: SLIT: nodes = 8 10 12 12 14 14 14 14 16 12 10 14 12 14 14 12 14 12 14 10 14 12 12 14 14 14 12 14 10 12 12 14 14 14 14 12 12 10 14 12 14 14 14 12 12 14 10 14 12 14 12 14 14 12 14 10 12 16 14 14 14 14 12 12 10 YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: > >> I don't quite understand the purpose of the patch to begin with. Looking > at > >> the current x86 git tree, apic_is_clustered_box is used only to determine > if > >> tsc is synchronized on the platform. The AMD docs imply that TSC's are > not > >> guaranteed to be synced across cores between nodes -- Opteron BKDG for > >> family 10h, Section 2.9.4: > > > >After long discussions with AMD they determined the CPUID flag > >for sync RDTSC will imply synchronization between nodes. > > Ah! > > > > > >If you can't support that in your hardware you're supposed > >to clear it. > > Hmm! How would a hardware vendor do that? That doesn't seem to be clear in > the BKDG. (Well, this is the problem with undocumented features :() > any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: >> I don't quite understand the purpose of the patch to begin with. Looking at >> the current x86 git tree, apic_is_clustered_box is used only to determine if >> tsc is synchronized on the platform. The AMD docs imply that TSC's are not >> guaranteed to be synced across cores between nodes -- Opteron BKDG for >> family 10h, Section 2.9.4: > >After long discussions with AMD they determined the CPUID flag >for sync RDTSC will imply synchronization between nodes. Ah! > >If you can't support that in your hardware you're supposed >to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() Thanks, Kiran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
> I don't quite understand the purpose of the patch to begin with. Looking at > the current x86 git tree, apic_is_clustered_box is used only to determine if > tsc is synchronized on the platform. The AMD docs imply that TSC's are not > guaranteed to be synced across cores between nodes -- Opteron BKDG for > family 10h, Section 2.9.4: After long discussions with AMD they determined the CPUID flag for sync RDTSC will imply synchronization between nodes. If you can't support that in your hardware you're supposed to clear it. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 02:05:45PM -0800, Yinghai Lu wrote: >On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai ><[EMAIL PROTECTED]> wrote: >> ... >> Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this >> check base on cpu vendor id is not good :(. > >please check if you happy with > >http://lkml.org/lkml/2008/2/24/273 > I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not guaranteed to be synced across cores between nodes -- Opteron BKDG for family 10h, Section 2.9.4: Note: Timers associated with different CPU cores in the same processor increment at the same rate. Timers associated with different CPU cores in different processors increment at slightly different rates if (1) they are located on different nodes and (2) CLKIN for these nodes is derived from different, non-synchronized oscillator sources. But that is not what the x86 tree does (with your patches) -- it looks for the X86_FEATURE_CONSTANT_TSC at unsynchronized_tsc() and assumes a synchronized clock. Huh!?? Am i missing something here? X86_FEATURE_CONSTANT_TSC is set from CPUID Fn8000_0007 -- TscInvariant bit, which implies TSC is not affected by change in PM states. This does not talk about whether CLKIN for different packages are from synchronized/non synchronized oscillator sources in the above quote. Thanks, Kiran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai <[EMAIL PROTECTED]> wrote: > On Sun, Feb 24, 2008 at 01:29:03PM +0100, Andi Kleen wrote: > >On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: > >> > >> quad core 8 socket system will have apic id lifting.the apic id range > could > >> be [4, 0x23]. and apic_is_clustered_box will think that need to three > clusters > >> and that is large than 2. So it is treated as clustered_box. > > > >Ok I see you chose the quick hack over doing it properly ... > > > >> > >> and will get > >> > >> Marking TSC unstable due to TSCs unsynchronized > >> > >> even the CPUs have X86_FEATURE_CONSTANT_TSC set. > > > >I doubt that will do the right thing on AMD based vSMP, > >which also required the cluster check on AMD iirc. > > > > Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this > check base on cpu vendor id is not good :(. please check if you happy with http://lkml.org/lkml/2008/2/24/273 Thanks Yinghai Lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sun, Feb 24, 2008 at 01:29:03PM +0100, Andi Kleen wrote: >On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: >> >> quad core 8 socket system will have apic id lifting.the apic id range could >> be [4, 0x23]. and apic_is_clustered_box will think that need to three >> clusters >> and that is large than 2. So it is treated as clustered_box. > >Ok I see you chose the quick hack over doing it properly ... > >> >> and will get >> >> Marking TSC unstable due to TSCs unsynchronized >> >> even the CPUs have X86_FEATURE_CONSTANT_TSC set. > >I doubt that will do the right thing on AMD based vSMP, >which also required the cluster check on AMD iirc. > Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this check base on cpu vendor id is not good :(. Thanks, Kiran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sun, Feb 24, 2008 at 01:29:03PM +0100, Andi Kleen wrote: On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. Ok I see you chose the quick hack over doing it properly ... and will get Marking TSC unstable due to TSCs unsynchronized even the CPUs have X86_FEATURE_CONSTANT_TSC set. I doubt that will do the right thing on AMD based vSMP, which also required the cluster check on AMD iirc. Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this check base on cpu vendor id is not good :(. Thanks, Kiran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Sun, Feb 24, 2008 at 01:29:03PM +0100, Andi Kleen wrote: On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. Ok I see you chose the quick hack over doing it properly ... and will get Marking TSC unstable due to TSCs unsynchronized even the CPUs have X86_FEATURE_CONSTANT_TSC set. I doubt that will do the right thing on AMD based vSMP, which also required the cluster check on AMD iirc. Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this check base on cpu vendor id is not good :(. please check if you happy with http://lkml.org/lkml/2008/2/24/273 Thanks Yinghai Lu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 02:05:45PM -0800, Yinghai Lu wrote: On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: ... Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this check base on cpu vendor id is not good :(. please check if you happy with http://lkml.org/lkml/2008/2/24/273 I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not guaranteed to be synced across cores between nodes -- Opteron BKDG for family 10h, Section 2.9.4: quote Note: Timers associated with different CPU cores in the same processor increment at the same rate. Timers associated with different CPU cores in different processors increment at slightly different rates if (1) they are located on different nodes and (2) CLKIN for these nodes is derived from different, non-synchronized oscillator sources. /quote But that is not what the x86 tree does (with your patches) -- it looks for the X86_FEATURE_CONSTANT_TSC at unsynchronized_tsc() and assumes a synchronized clock. Huh!?? Am i missing something here? X86_FEATURE_CONSTANT_TSC is set from CPUID Fn8000_0007 -- TscInvariant bit, which implies TSC is not affected by change in PM states. This does not talk about whether CLKIN for different packages are from synchronized/non synchronized oscillator sources in the above quote. Thanks, Kiran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not guaranteed to be synced across cores between nodes -- Opteron BKDG for family 10h, Section 2.9.4: After long discussions with AMD they determined the CPUID flag for sync RDTSC will imply synchronization between nodes. If you can't support that in your hardware you're supposed to clear it. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not guaranteed to be synced across cores between nodes -- Opteron BKDG for family 10h, Section 2.9.4: After long discussions with AMD they determined the CPUID flag for sync RDTSC will imply synchronization between nodes. Ah! If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() Thanks, Kiran -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote: I don't quite understand the purpose of the patch to begin with. Looking at the current x86 git tree, apic_is_clustered_box is used only to determine if tsc is synchronized on the platform. The AMD docs imply that TSC's are not guaranteed to be synced across cores between nodes -- Opteron BKDG for family 10h, Section 2.9.4: After long discussions with AMD they determined the CPUID flag for sync RDTSC will imply synchronization between nodes. Ah! If you can't support that in your hardware you're supposed to clear it. Hmm! How would a hardware vendor do that? That doesn't seem to be clear in the BKDG. (Well, this is the problem with undocumented features :() any good sign for APIC_clustered box? there is apicid between cpus even all cpu are quadcore and fully populated? YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sun, Feb 24, 2008 at 4:29 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: > > > > quad core 8 socket system will have apic id lifting.the apic id range could > > be [4, 0x23]. and apic_is_clustered_box will think that need to three > clusters > > and that is large than 2. So it is treated as clustered_box. > > Ok I see you chose the quick hack over doing it properly ... you didn't answer my question: for IBM Summit2, Unisys ES7000, and ScaleMP vSMP, if call cpus sockets are fully populated with quadcore cpus, do they still have hole between apic id? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
please check the fix for v2.
this one can be applied to x86.git#testing
YH
---
[PATCH] x86_64: apic_is_clustered_box fix for vsmp
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
v2 patch will check if the cpu is from AMD.
vsmp still need that checking...
this patch is fix for vsmp
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index 8f6c45e..8a47579 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void)
* there is not this kind of box with AMD CPU yet.
* Some AMD box with quadcore cpu and 8 sockets apicid
* will be [4, 0x23] or [8, 0x27] could be thought to
-* have three apic_clusters. So go out early.
+* vsmp box still need checking...
*/
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
return 0;
bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 54202b1..09e16ff 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 type, u16 clobbers,
void *ibuf,
}
+static int vsmp = -1;
+
+int is_vsmp_box(void)
+{
+ if (vsmp != -1)
+ return vsmp;
+
+ vsmp = 0;
+ if (!early_pci_allowed())
+ return vsmp;
+
+ /* Check if we are running on a ScaleMP vSMP box */
+ if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
+ vsmp = 1;
+
+ return vsmp;
+}
+
void __init vsmp_init(void)
{
void *address;
unsigned int cap, ctl, cfg;
- if (!early_pci_allowed())
+ if (!vsmp)
return;
- /* Check if we are running on a ScaleMP vSMP box */
- if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
- (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+ if (!early_pci_allowed())
return;
/* If we are, use the distinguished irq functions */
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index a68dc6b..24f7a05 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
*/
#ifdef CONFIG_PARAVIRT
#include
+extern int is_vsmp_box(void);
#else
#define apic_write native_apic_write
#define apic_write_atomic native_apic_write_atomic
#define apic_read native_apic_read
#define setup_boot_clock setup_boot_APIC_clock
#define setup_secondary_clock setup_secondary_APIC_clock
+int inline is_vsmp_box(void)
+{
+ return 0;
+}
#endif
static inline void native_apic_write(unsigned long reg, u32 v)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sunday 24 February 2008 03:00:52 pm Yinghai Lu wrote:
> On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote:
> > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
> > >
> > > quad core 8 socket system will have apic id lifting.the apic id range
> > > could
> > > be [4, 0x23]. and apic_is_clustered_box will think that need to three
> > > clusters
> > > and that is large than 2. So it is treated as clustered_box.
> >
> > Ok I see you chose the quick hack over doing it properly ...
> >
> > >
> > > and will get
> > >
> > > Marking TSC unstable due to TSCs unsynchronized
> > >
> > > even the CPUs have X86_FEATURE_CONSTANT_TSC set.
> >
> > I doubt that will do the right thing on AMD based vSMP,
> > which also required the cluster check on AMD iirc.
> >
> > Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.
>
> do you have bootlog for these box?
>
> IBM summit2, Unisys es7, and system from scalemp..
>
> DMI could tell the difference?
i produced one patch against linus tree. but it can not be applied to
x86/testing
x86/testing has
obj-$(CONFIG_PARAVIRT) += vsmp_64.o
so my question: is the vsmp the real HW or just in paravirt?
YH
[PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v3
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
this patch will check if the cpu is from AMD.
also vsmp still need that checking...
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4eb5ce8..2bec799 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o
crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
obj-$(CONFIG_X86_NUMAQ)+= numaq_32.o
obj-$(CONFIG_X86_SUMMIT_NUMA) += summit_32.o
-obj-$(CONFIG_X86_VSMP) += vsmp_64.o
+obj-y += vsmp_64.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_MODULES) += module_$(BITS).o
obj-$(CONFIG_ACPI_SRAT)+= srat_32.o
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..1427ec3 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,20 @@ __cpuinit int apic_is_clustered_box(void)
{
int i, clusters, zeros;
unsigned id;
- u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+ u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+ /*
+* there is not this kind of box with AMD CPU yet.
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+* vsmp box still need checking...
+*/
+ if (!is_vsmp_box() && (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+ return 0;
+
+ bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
for (i = 0; i < NR_CPUS; i++) {
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index d971210..2780df1 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -16,19 +16,35 @@
#include
#include
+static int vsmp = -1;
+
+__cpuinit int is_vsmp_box(void)
+{
+ if (vsmp != -1)
+ return vsmp;
+
+ vsmp = 0;
+ if (!early_pci_allowed())
+ return vsmp;
+
+ /* Check if we are running on a ScaleMP vSMP box */
+ if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL << 16)))
+ vsmp = 1;
+
+ return vsmp;
+}
+
+#ifdef CONFIG_X86_VSMP
static int __init vsmp_init(void)
{
void *address;
unsigned int cap, ctl;
- if (!early_pci_allowed())
+ if (!vsmp)
return 0;
- /* Check if we are running on a ScaleMP vSMP box */
- if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
- (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+ if (!early_pci_allowed())
return 0;
/* set vSMP magic bits to indicate vSMP capable kernel */
@@ -50,3 +66,4 @@ static int __init vsmp_init(void)
}
core_initcall(vsmp_init);
+#endif
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index bcfc07f..d69f596 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -130,6 +130,7 @@ extern u8 setup_APIC_eilvt_mce(u8 vector, u8 msg_type, u8
mask);
extern u8 setup_APIC_eilvt_ibs(u8 vector, u8
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote: > On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: > > > > quad core 8 socket system will have apic id lifting.the apic id range could > > be [4, 0x23]. and apic_is_clustered_box will think that need to three > > clusters > > and that is large than 2. So it is treated as clustered_box. > > Ok I see you chose the quick hack over doing it properly ... > > > > > and will get > > > > Marking TSC unstable due to TSCs unsynchronized > > > > even the CPUs have X86_FEATURE_CONSTANT_TSC set. > > I doubt that will do the right thing on AMD based vSMP, > which also required the cluster check on AMD iirc. > > Cc'ed Kiran/Shai. damage has already hit x86 tree I believe. do you have bootlog for these box? IBM summit2, Unisys es7, and system from scalemp.. DMI could tell the difference? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
>
> quad core 8 socket system will have apic id lifting.the apic id range could
> be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
> and that is large than 2. So it is treated as clustered_box.
Ok I see you chose the quick hack over doing it properly ...
>
> and will get
>
> Marking TSC unstable due to TSCs unsynchronized
>
> even the CPUs have X86_FEATURE_CONSTANT_TSC set.
I doubt that will do the right thing on AMD based vSMP,
which also required the cluster check on AMD iirc.
Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.
-Andi
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..7d8ffda 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
{
int i, clusters, zeros;
unsigned id;
- u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+ u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+ /*
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+*/
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
Ok I see you chose the quick hack over doing it properly ...
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
I doubt that will do the right thing on AMD based vSMP,
which also required the cluster check on AMD iirc.
Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.
-Andi
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..7d8ffda 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,19 @@ __cpuinit int apic_is_clustered_box(void)
{
int i, clusters, zeros;
unsigned id;
- u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+ u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+ /*
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+*/
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote: On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. Ok I see you chose the quick hack over doing it properly ... and will get Marking TSC unstable due to TSCs unsynchronized even the CPUs have X86_FEATURE_CONSTANT_TSC set. I doubt that will do the right thing on AMD based vSMP, which also required the cluster check on AMD iirc. Cc'ed Kiran/Shai. damage has already hit x86 tree I believe. do you have bootlog for these box? IBM summit2, Unisys es7, and system from scalemp.. DMI could tell the difference? YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sunday 24 February 2008 03:00:52 pm Yinghai Lu wrote:
On Sunday 24 February 2008 04:29:03 am Andi Kleen wrote:
On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote:
quad core 8 socket system will have apic id lifting.the apic id range
could
be [4, 0x23]. and apic_is_clustered_box will think that need to three
clusters
and that is large than 2. So it is treated as clustered_box.
Ok I see you chose the quick hack over doing it properly ...
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
I doubt that will do the right thing on AMD based vSMP,
which also required the cluster check on AMD iirc.
Cc'ed Kiran/Shai. damage has already hit x86 tree I believe.
do you have bootlog for these box?
IBM summit2, Unisys es7, and system from scalemp..
DMI could tell the difference?
i produced one patch against linus tree. but it can not be applied to
x86/testing
x86/testing has
obj-$(CONFIG_PARAVIRT) += vsmp_64.o
so my question: is the vsmp the real HW or just in paravirt?
YH
[PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v3
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
this patch will check if the cpu is from AMD.
also vsmp still need that checking...
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 4eb5ce8..2bec799 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o
crash.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump_$(BITS).o
obj-$(CONFIG_X86_NUMAQ)+= numaq_32.o
obj-$(CONFIG_X86_SUMMIT_NUMA) += summit_32.o
-obj-$(CONFIG_X86_VSMP) += vsmp_64.o
+obj-y += vsmp_64.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_MODULES) += module_$(BITS).o
obj-$(CONFIG_ACPI_SRAT)+= srat_32.o
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index d8d03e0..1427ec3 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1180,9 +1180,20 @@ __cpuinit int apic_is_clustered_box(void)
{
int i, clusters, zeros;
unsigned id;
- u16 *bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
+ u16 *bios_cpu_apicid;
DECLARE_BITMAP(clustermap, NUM_APIC_CLUSTERS);
+ /*
+* there is not this kind of box with AMD CPU yet.
+* Some AMD box with quadcore cpu and 8 sockets apicid
+* will be [4, 0x23] or [8, 0x27] could be thought to
+* have three apic_clusters. So go out early.
+* vsmp box still need checking...
+*/
+ if (!is_vsmp_box() (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+ return 0;
+
+ bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
bitmap_zero(clustermap, NUM_APIC_CLUSTERS);
for (i = 0; i NR_CPUS; i++) {
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index d971210..2780df1 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -16,19 +16,35 @@
#include asm/pci-direct.h
#include asm/io.h
+static int vsmp = -1;
+
+__cpuinit int is_vsmp_box(void)
+{
+ if (vsmp != -1)
+ return vsmp;
+
+ vsmp = 0;
+ if (!early_pci_allowed())
+ return vsmp;
+
+ /* Check if we are running on a ScaleMP vSMP box */
+ if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL 16)))
+ vsmp = 1;
+
+ return vsmp;
+}
+
+#ifdef CONFIG_X86_VSMP
static int __init vsmp_init(void)
{
void *address;
unsigned int cap, ctl;
- if (!early_pci_allowed())
+ if (!vsmp)
return 0;
- /* Check if we are running on a ScaleMP vSMP box */
- if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
- (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+ if (!early_pci_allowed())
return 0;
/* set vSMP magic bits to indicate vSMP capable kernel */
@@ -50,3 +66,4 @@ static int __init vsmp_init(void)
}
core_initcall(vsmp_init);
+#endif
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index bcfc07f..d69f596 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -130,6 +130,7 @@ extern u8 setup_APIC_eilvt_mce(u8 vector, u8 msg_type, u8
mask);
extern u8 setup_APIC_eilvt_ibs(u8 vector, u8 msg_type, u8 mask);
extern int
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
please check the fix for v2.
this one can be applied to x86.git#testing
YH
---
[PATCH] x86_64: apic_is_clustered_box fix for vsmp
quad core 8 socket system will have apic id lifting.the apic id range could
be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters
and that is large than 2. So it is treated as clustered_box.
and will get
Marking TSC unstable due to TSCs unsynchronized
even the CPUs have X86_FEATURE_CONSTANT_TSC set.
v2 patch will check if the cpu is from AMD.
vsmp still need that checking...
this patch is fix for vsmp
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index 8f6c45e..8a47579 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -1206,9 +1206,9 @@ __cpuinit int apic_is_clustered_box(void)
* there is not this kind of box with AMD CPU yet.
* Some AMD box with quadcore cpu and 8 sockets apicid
* will be [4, 0x23] or [8, 0x27] could be thought to
-* have three apic_clusters. So go out early.
+* vsmp box still need checking...
*/
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ if (!is_vsmp_box() (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
return 0;
bios_cpu_apicid = x86_bios_cpu_apicid_early_ptr;
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 54202b1..09e16ff 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -72,19 +72,34 @@ static unsigned __init vsmp_patch(u8 type, u16 clobbers,
void *ibuf,
}
+static int vsmp = -1;
+
+int is_vsmp_box(void)
+{
+ if (vsmp != -1)
+ return vsmp;
+
+ vsmp = 0;
+ if (!early_pci_allowed())
+ return vsmp;
+
+ /* Check if we are running on a ScaleMP vSMP box */
+ if (read_pci_config(0, 0x1f, 0, PCI_VENDOR_ID) ==
+(PCI_VENDOR_ID_SCALEMP || (PCI_DEVICE_ID_SCALEMP_VSMP_CTL 16)))
+ vsmp = 1;
+
+ return vsmp;
+}
+
void __init vsmp_init(void)
{
void *address;
unsigned int cap, ctl, cfg;
- if (!early_pci_allowed())
+ if (!vsmp)
return;
- /* Check if we are running on a ScaleMP vSMP box */
- if ((read_pci_config_16(0, 0x1f, 0, PCI_VENDOR_ID) !=
-PCI_VENDOR_ID_SCALEMP) ||
- (read_pci_config_16(0, 0x1f, 0, PCI_DEVICE_ID) !=
-PCI_DEVICE_ID_SCALEMP_VSMP_CTL))
+ if (!early_pci_allowed())
return;
/* If we are, use the distinguished irq functions */
diff --git a/include/asm-x86/apic.h b/include/asm-x86/apic.h
index a68dc6b..24f7a05 100644
--- a/include/asm-x86/apic.h
+++ b/include/asm-x86/apic.h
@@ -51,12 +51,17 @@ extern unsigned boot_cpu_id;
*/
#ifdef CONFIG_PARAVIRT
#include asm/paravirt.h
+extern int is_vsmp_box(void);
#else
#define apic_write native_apic_write
#define apic_write_atomic native_apic_write_atomic
#define apic_read native_apic_read
#define setup_boot_clock setup_boot_APIC_clock
#define setup_secondary_clock setup_secondary_APIC_clock
+int inline is_vsmp_box(void)
+{
+ return 0;
+}
#endif
static inline void native_apic_write(unsigned long reg, u32 v)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
On Sun, Feb 24, 2008 at 4:29 AM, Andi Kleen [EMAIL PROTECTED] wrote: On Sat, Feb 23, 2008 at 09:48:42PM -0800, Yinghai Lu wrote: quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. Ok I see you chose the quick hack over doing it properly ... you didn't answer my question: for IBM Summit2, Unisys ES7000, and ScaleMP vSMP, if call cpus sockets are fully populated with quadcore cpus, do they still have hole between apic id? YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
* Yinghai Lu <[EMAIL PROTECTED]> wrote: > quad core 8 socket system will have apic id lifting.the apic id range > could be [4, 0x23]. and apic_is_clustered_box will think that need to > three clusters and that is large than 2. So it is treated as > clustered_box. > > and will get > > Marking TSC unstable due to TSCs unsynchronized > > even the CPUs have X86_FEATURE_CONSTANT_TSC set. > > this patch will check if the cpu is from AMD. thanks Yinghai, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box v2
* Yinghai Lu [EMAIL PROTECTED] wrote: quad core 8 socket system will have apic id lifting.the apic id range could be [4, 0x23]. and apic_is_clustered_box will think that need to three clusters and that is large than 2. So it is treated as clustered_box. and will get Marking TSC unstable due to TSCs unsynchronized even the CPUs have X86_FEATURE_CONSTANT_TSC set. this patch will check if the cpu is from AMD. thanks Yinghai, applied. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
