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(-) -- 2.19.2
