On Friday 22 February 2008 11:02:30 am Yinghai Lu wrote: > On Friday 22 February 2008 04:25:18 am Andi Kleen wrote: > > Yinghai Lu <[EMAIL PROTECTED]> writes: > > > > > quad core 8 socket system will have apic id lifting.the apic id range > > > could > > > be [4, 0x23]. or [8, 0x27]. 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 offset back the apic before get apic clusterid. > > > > > > or use dmi to get apic_is_clustered? > > > > The clustered check is for Summit and es7000 systems > > On 64bit systems it might be actually possible to trigger > > this based on SLIT instead. But you'll need to check with > > the IBM Summit/Unisys es7000 developers if that works or not > > > > If you don't want to do that the safer way would be probably > > the check if there are holes between the CPUs APIC numbers. > > If yes then it's likely clustered mode. I think that would > > be better than to disable it unconditionally for apic lifting > > like your patches does. > > so for that box [4, 0x23] still could be apic clustered? there is a hole > [0,3].. > > is their box using AMD cpu or not?
or move CPUs have X86_FEATURE_CONSTANT_TSC check before apic_clustered check? 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/
