My newly acquired AMD Ryzen Threadripper based system seems to have
some TSC quirks, which go away once the system is up.
Given the discussion in https://lkml.org/lkml/2019/1/28/1356
I don't seem to be the only one, and it does not seem to be
Threadripper specific.
The first patch addresses presumably SMI interruptions, that occur
on my system at a 60 Hz frequency. They take too long, making the
existing code fail. The patch makes that code more resilient.
(These interruptions go away at some point during boot; also proven
by the fact, that I don't have any TSC issues, when kexecing into
a new kernel.)
The second patch prevents TSC going unstable when resuming from S3.
This may have a similar source, but is certainly more weird: the
TSC is observed to go backwards on CPU0 by about 200 to 500 cycles
compared to other CPUs every once in a while, as long as its sibling
(CPU16 in my case) hasn't been resumed yet. (I did some experiments
with CPU hotplug before and after suspend, but apart from reproducing
the issue and verifying the "fix", I got nowhere.)
The patches are against v4.20.
Jan H. SchÃnherr (2):
x86/tsc: Allow quick PIT calibration despite interruptions
cpu/hotplug: Unfreeze sibling CPU first on resume from S3
arch/x86/kernel/tsc.c | 80 +++++++++++++++++++++++++------------------
kernel/cpu.c | 34 ++++++++++++------
2 files changed, 70 insertions(+), 44 deletions(-)
[ 0.000000] DMI: HP HP EliteDesk 705 G4 MT/83E7, BIOS Q06 Ver. 02.04.01 09/14/2018
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 3616.864 MHz processor