Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 20 Mar 2018 10:00:09 +0100 (CET)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Liu, Changcheng" <changcheng.liu@intel.com>
cc:     hpa@zytor.com, peterz@infradead.org, douly.fnst@cn.fujitsu.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/ioapic: don't use unstable TSC to detect timer IRQ
In-Reply-To: <20180320084255.GA187704@sofia>
Message-ID: <alpine.DEB.2.21.1803200956580.6506@nanos.tec.linutronix.de>
References: <20180320084255.GA187704@sofia>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 20 Mar 2018, Liu, Changcheng wrote:

> In rare case, the TSC is every unstable or can't sync with
> real time hardware clock.

What does that mean?

> After setting "tsc=unstable" in command line, system should use
> delay_without_tsc to detect timer IRQ. Or system could panic as shown in
> below log:

tsc=unstable has nothing to do with TSC being usable for delay loops unless
your TSC is completely broken. Please explain more detailed in which way
this TSC is defect in the hardware. Aside of that is this production
hardware or some experimental silicon?

> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index fb43027..27b1bae 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -36,7 +36,8 @@ EXPORT_SYMBOL(tsc_khz);
>  /*
>   * TSC can be unstable due to cpufreq or due to unsynced TSCs
>   */
> -static int __read_mostly tsc_unstable;
> +int __read_mostly tsc_unstable;
> +EXPORT_SYMBOL(tsc_unstable);

Even if we decided to do that, there is no need to export that symbol ever.

Thanks,

	tglx