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