[BUG] x86/tsc: ~1 second TSC skew when bringing a secondary CPU online on Ryzen 7 8840HS

[BUG] x86/tsc: ~1 second TSC skew when bringing a secondary CPU online on Ryzen 7 8840HS

[David Kostial]

Hi,

I'm seeing a large and reproducible TSC synchronization error on a
Lenovo Yoga 7 2-in-1 14AHP9 with an AMD Ryzen 7 8840HS.

It also reproduces with a vanilla kernel built from Linus' tree:

  commit 15ef2f78c49d20d53ec7c0f1c9b40b02e089f2d6
  v7.2-rc7-219-g15ef2f78c49d
  7.2.0-rc7-katinka-tsc-00219-g15ef2f78c49d

The kernel was untainted during the tests and no DKMS or other
out-of-tree modules were loaded.

Hardware / firmware:

  System:       Lenovo Yoga 7 2-in-1 14AHP9 (83DK)
  CPU:          AMD Ryzen 7 8840HS
  Family:       0x19 (25)
  Model:        0x75 (117)
  Stepping:     2
  BIOS:         P9CN33WW, 2026-03-27
  AGESA:        PhoenixPI-FP8-FP7 1.2.0.0f
  Microcode:    0x0a70520a

The CPU reports constant_tsc and nonstop_tsc.

A normal boot with all 16 logical CPUs already triggers the problem.
TSC synchronization fails while the secondary CPUs are brought up,
TSC is marked unstable, and the kernel switches to HPET.

I found a simple deterministic reproducer using CPU hotplug.

Boot with:

  maxcpus=1

With only CPU0 online:

  $ cat /sys/devices/system/cpu/online
  0

  $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
  tsc

  $ cat /proc/sys/kernel/tainted
  0

Before CPU1 is brought online, TSC is selected as the current
clocksource and no TSC synchronization failure is logged.

Then bring CPU1 online:

  # echo 1 > /sys/devices/system/cpu/cpu1/online

This immediately gives:

  smpboot: Booting Node 0 Processor 1 APIC 0x1
  TSC synchronization [CPU#0 -> CPU#1]:
  Measured 3360957369 cycles TSC warp between CPUs, turning off TSC clock.
  tsc: Marking TSC unstable due to check_tsc_sync_source failed
  TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
  clocksource: Switched to clocksource hpet

After that:

  $ cat /sys/devices/system/cpu/online
  0-1

  $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
  hpet

  $ cat /proc/sys/kernel/tainted
  0

With the full CPU topology online, CPU0 and CPU1 are SMT siblings of
the same physical core.

The result is very repeatable. Across different tests I have seen TSC
warps between roughly 3.25 and 3.36 billion cycles.

I have reproduced the same type of failure with Debian kernels based
on Linux 6.12.101, 7.1.3, and 7.2-rc7.

I also tried:

  - cold boot: affected
  - BIOS Fast Boot setting enabled/disabled: no difference
  - BIOS AMD SVM setting enabled/disabled: no difference
  - CPU0 only: TSC is selected
  - bringing a secondary logical CPU online: TSC becomes unstable

The kernel falls back to HPET after detecting the skew.

I also saw the following KVM warning on the affected system when
starting an SMP guest:

  kvm: SMP vm created on host with unstable TSC; guest TSC will not be reliable

I'm not sure whether the root cause is firmware/AGESA or whether there
is anything x86/tsc should handle differently here.

Is there any additional TSC instrumentation, MSR data, trace data, or
firmware information that would be useful?

I also have a redacted 92 KiB diagnostic archive containing the full
vanilla dmesg, kernel config, lscpu output, CPU/APIC topology,
microcode and firmware information, and the normal-boot and CPU-hotplug
reproducer logs. I can provide it if useful.

Regards,
David Kostial

Re: [BUG] x86/tsc: ~1 second TSC skew when bringing a secondary CPU online on Ryzen 7 8840HS

[Thomas Gleixner]

On Sat, Aug 15 2026 at 20:17, David Kostial wrote:
>   smpboot: Booting Node 0 Processor 1 APIC 0x1
>   TSC synchronization [CPU#0 -> CPU#1]:
>   Measured 3360957369 cycles TSC warp between CPUs, turning off TSC clock.
>   tsc: Marking TSC unstable due to check_tsc_sync_source failed
>   TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
>   clocksource: Switched to clocksource hpet
....
> I'm not sure whether the root cause is firmware/AGESA or whether there
> is anything x86/tsc should handle differently here.

That's a firmware problem. The firmware messes up the TSC synchronization.

The kernel can't do anything about this as the CPU does not have the
TSC_ADJUST MSR.

We tried to write to the TSC MSR directly, but that turned out to be
fragile and unreliable so we restricted the fixup attempts to CPUs which
have the TSC_ADJUST MSR.

Thanks,

        tglx