Date: Wed, 13 Dec 2017 12:14:14 +0200
From: Dan Aloni <dan@kernelim.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org,
        Linux Kernel List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Bin Gao <bin.gao@linux.intel.com>
Subject: Re: TSC x86 fixes for LTS kernel 4.9.x
Message-ID: <20171213101414.GA4365@gmail.com>
References: <20171213083352.GA15356@gmail.com>
 <20171213090335.GA5496@kroah.com>
 <20171213094520.GA23556@gmail.com>
 <20171213095755.GA15957@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171213095755.GA15957@kroah.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2253
Lines: 53

On Wed, Dec 13, 2017 at 10:57:55AM +0100, Greg KH wrote:
> On Wed, Dec 13, 2017 at 11:45:20AM +0200, Dan Aloni wrote:
> > git cherry-pick -x 16588f659257 # x86/tsc: Annotate printouts as firmware bug
> > git cherry-pick -x 8c9b9d87b855 # x86/tsc: Limit the adjust value further
> > 
> > There's a conflict only in a one small place in the first few patches.
>[..]
> That's a lot of changes to be backported.  I'm _really_ hesitant to do
> this, unless the maintainer of the code agrees it is ok...

I guessed so, that's why I probed. Otherwise I would have just sent
out patches.

> > > > These changes percisely fix an issue I am having with a relatively new
> > > > 8-core Intel(R) Core(TM) i7-7820X with an updated ASUS BIOS (December 2017).
> > > > 
> > > > Under v4.9.68, the kernel fallbacks on the chosen clocksource to HPET which
> > > > just doesn't work - there is over a 200ms time drift that does not go
> > > > away even after repeated ntpdate sync attempts.
> > > > 
> > > > For further testing I've posted a branch for these changes here:
> > > > 
> > > >     https://github.com/kernelim/linux tsc-fix-for-4.9.x
> > > 
> > > Why not just use 4.14 instead?  That's much easier than trying to use an
> > > old kernel like 4.9, right?
> > 
> > Yes, however the milage of 4.9.x seems more appealing somewhat.
> 
> Why?  4.14 should be much better, it's newer, has more hardware support,
> more bugs fixed, and more new things left to debug :)

I always enjoy debugging :)

> > I'll give 4.14.x a try mostly to see whether it solves hard locks that
> > I've seen with 4.13.x (all Fedora-based stable kernels) on three of my
> > machines -- an unrelated issue, and the main reason why I gave one of
> > the LTS branches a try.
>
> You really should report that.  Without that, odds are it will not be
> fixed.

I am still collecting data, but these systems are being used rather
constantly so the downtime is problematic. It's a) a rather new
workstation, 2) an Intel Nuc, and 3) An old Lenovo Carbon X1 Gen 3.

I should have also used a vanilla build because I know that on LKML
it has preference over the Fedora-based patchset. I will try to see
if it produces on 4.14.x and perhaps kdump will be able to capture
it this time.

-- 
Dan Aloni