TSC marked unstable on AMD Zen4 (Ryzen 7 250, ThinkBook 16 G9 AHP): 15.6G-cycle warp CPU0->CPU2 at boot, 7.1.12

["A Kundu" <avikalpa@yahoo.com>]

Hi,

On an AMD Zen4 laptop, kernel 7.1.12 (x86_64) marks the TSC unstable at
boot with a massive cross-CPU warp:

[    0.191568] TSC synchronization [CPU#0 -> CPU#2]:
[    0.191571] Measured 15645116622 cycles TSC warp between CPUs, turning off TSC clock.
[    0.191580] tsc: Marking TSC unstable due to check_tsc_sync_source failed

That is 15,645,116,622 cycles (~4.7 s at the detected 3294 MHz) of skew
between CPU0 and CPU2 during early-boot synchronization. The kernel then
runs on HPET; the TSC is dropped from the available clocksource list
entirely.

Hardware: AMD Ryzen 7 250 w/ Radeon 780M (Zen4), single socket, constant_tsc
+ nonstop_tsc + rdtscp present. Lenovo ThinkBook 16 G9 AHP (type 21UT),
BIOS SQCN20WW dated 2025-11-10 (latest published for this model).

Notes:

- A previous boot configuration used the `tsc=reliable` parameter, which
  forced the skewed TSC into service. Applications then observed
  multi-second backwards jumps of CLOCK_MONOTONIC depending on the CPU
  they ran on (Chromium renderer CHECK failures; journald boot accounting
  disorder). The parameter had been masking this boot-time failure.
- The warp magnitude — seconds, not a small calibration drift — suggests
  the secondary CPU's TSC was never synchronized by firmware rather than
  a measurement issue in check_tsc_sync_source.
- Suggest Lenovo/AMD be looked at for the firmware-side sync, but the
  kernel-side behaviour (boot-time detection working as designed) is
  reported here for the record since 15.6G cycles is far outside anything
  a retry would paper over.

Full dmesg, CPUID dumps and further data available on request. Happy to
test patches.

Thanks,
Avikalpa Kundu