On Wed, Dec 13, 2017 at 10:33:52AM +0200, Dan Aloni wrote: > Hi all, > > I've tested the following changes, belonging to merge commit f7dd3b1734e, > on top of 4.9.68 after a very easy backport from 4.10, and I think it > may be worthwhile adding them to 4.9.x: > > x86/tsc: Limit the adjust value further > x86/tsc: Annotate printouts as firmware bug > x86/tsc: Force TSC_ADJUST register to value >= zero > x86/tsc: Validate TSC_ADJUST after resume > x86/tsc: Validate cpumask pointer before accessing it > x86/tsc: Fix broken CONFIG_X86_TSC=n build > x86/tsc: Try to adjust TSC if sync test fails > x86/tsc: Prepare warp test for TSC adjustment > x86/tsc: Move sync cleanup to a safe place > x86/tsc: Sync test only for the first cpu in a package > x86/tsc: Verify TSC_ADJUST from idle > x86/tsc: Store and check TSC ADJUST MSR > x86/tsc: Detect random warps > x86/tsc: Use X86_FEATURE_TSC_ADJUST in detect_art() > x86/tsc: Finalize the split of the TSC_RELIABLE flag > x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs > x86/tsc: Mark Intel ATOM_GOLDMONT TSC reliable > x86/tsc: Mark TSC frequency determined by CPUID as known > x86/tsc: Add X86_FEATURE_TSC_KNOWN_FREQ flag I need git commit ids to be able to do anything :) > 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? thanks, greg k-h