To: Yinghai Lu <Yinghai.Lu@Sun.COM>
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box
From: Andi Kleen <andi@firstfloor.org>
References: <200802210258.45011.yinghai.lu@sun.com>
Date: Fri, 22 Feb 2008 13:25:18 +0100
In-Reply-To: <200802210258.45011.yinghai.lu@sun.com> (Yinghai Lu's message of "Thu\, 21 Feb 2008 02\:58\:44 -0800")
Message-ID: <p73hcg189g1.fsf@bingen.suse.de>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1249
Lines: 33

Yinghai Lu <Yinghai.Lu@Sun.COM> 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.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/