[Bug 2166715] [NEW] Clocksource watchdog intermittently demotes TSC to HPET on Ryzen 7 5700G with constant_tsc + nonstop_tsc

Public bug reported: On an ASUS ROG STRIX G10DK (AMD Ryzen 7 5700G), the kernel's clocksource watchdog marks the TSC unstable at boot and falls back to HPET — but only on *some* boots. The same kernel, unchanged configuration, boots to `tsc` other times. It behaves like a race against the machine still settling: the skew is measured about 2.1 s into boot. ``` [ 1.477709] clocksource: Switched to clocksource tsc [ 2.109340] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: [ 2.109345] clocksource: 'hpet' wd_nsec: 499479123 wd_now: 1b9c972 wd_last: 14ca962 [ 2.109348] clocksource: 'tsc' cs_nsec: 495996007 cs_now: 19355aab4a cs_last: 18c439320a [ 2.109351] clocksource: Clocksource 'tsc' skewed -3483116 ns (-3 ms) over watchdog 'hpet' interval of 499479123 ns (499 ms) [ 2.109358] tsc: Marking TSC unstable due to clocksource watchdog [ 2.109365] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 2.109494] clocksource: Switched to clocksource hpet ``` The CPU advertises `constant_tsc`, `nonstop_tsc` and `rdtscp`, i.e. an invariant TSC. **Observed across kernels — this is not a regression in any one version:** | date | kernel | resulting clocksource | |---|---|---| | 2026-07-22/23 | 7.0.0-28, 6.17.0-40, 6.8.0-136 | tsc ×8, hpet ×4 | | 2026-07-30 | 6.8.0-136 | hpet | | 2026-08-06 | 6.8.0-137 | hpet | | 2026-08-18 | 6.8.0-138 | hpet | | 2026-08-26 | 6.8.0-138 | tsc | | 2026-09-06 | 6.8.0-139 | hpet | | 2026-09-07 | 6.8.0-139 | tsc | | 2026-09-07 | 7.0.0-31 | hpet | **Impact:** This is not cosmetic. With HPET, `clock_gettime` stops being served from the vDSO and becomes a syscall with an MMIO hardware read. Measured on this machine, 200,000 iterations: - `hpet`: **1522 ns** per call - `tsc`: **103 ns** per call Any application that queries time frequently pays ~15× more. In my case Thunderbird 155 became completely unusable — its UI thread issues ~21,000 `clock_gettime`/s and saturated a core, with menus refusing to open. The same Thunderbird on the same profile runs at ~10% CPU once the clocksource is `tsc`. Because the demotion is intermittent, the resulting symptom looks random and gets misattributed to whatever application happens to notice it first. **Workaround:** `tsc=reliable` on the kernel command line. After that the machine boots to `tsc` every time and the symptom is gone. **Suggestion:** The kernel's own message points at the BIOS, and that may well be correct — but this board's last BIOS is from 2022-12-14 and the vendor has published nothing since, so there is no firmware fix available. Given the CPU declares an invariant TSC, it may be worth either running the watchdog later in boot, or being less eager to demote on CPUs that advertise `constant_tsc` + `nonstop_tsc`. **System:** Ubuntu 24.04.4 · ASUS ROG STRIX G10DK, BIOS 310 (2022-12-14) · AMD Ryzen 7 5700G ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166715 Title: Clocksource watchdog intermittently demotes TSC to HPET on Ryzen 7 5700G with constant_tsc + nonstop_tsc Status in linux package in Ubuntu: New Bug description: On an ASUS ROG STRIX G10DK (AMD Ryzen 7 5700G), the kernel's clocksource watchdog marks the TSC unstable at boot and falls back to HPET — but only on *some* boots. The same kernel, unchanged configuration, boots to `tsc` other times. It behaves like a race against the machine still settling: the skew is measured about 2.1 s into boot. ``` [ 1.477709] clocksource: Switched to clocksource tsc [ 2.109340] clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: [ 2.109345] clocksource: 'hpet' wd_nsec: 499479123 wd_now: 1b9c972 wd_last: 14ca962 [ 2.109348] clocksource: 'tsc' cs_nsec: 495996007 cs_now: 19355aab4a cs_last: 18c439320a [ 2.109351] clocksource: Clocksource 'tsc' skewed -3483116 ns (-3 ms) over watchdog 'hpet' interval of 499479123 ns (499 ms) [ 2.109358] tsc: Marking TSC unstable due to clocksource watchdog [ 2.109365] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. [ 2.109494] clocksource: Switched to clocksource hpet ``` The CPU advertises `constant_tsc`, `nonstop_tsc` and `rdtscp`, i.e. an invariant TSC. **Observed across kernels — this is not a regression in any one version:** | date | kernel | resulting clocksource | |---|---|---| | 2026-07-22/23 | 7.0.0-28, 6.17.0-40, 6.8.0-136 | tsc ×8, hpet ×4 | | 2026-07-30 | 6.8.0-136 | hpet | | 2026-08-06 | 6.8.0-137 | hpet | | 2026-08-18 | 6.8.0-138 | hpet | | 2026-08-26 | 6.8.0-138 | tsc | | 2026-09-06 | 6.8.0-139 | hpet | | 2026-09-07 | 6.8.0-139 | tsc | | 2026-09-07 | 7.0.0-31 | hpet | **Impact:** This is not cosmetic. With HPET, `clock_gettime` stops being served from the vDSO and becomes a syscall with an MMIO hardware read. Measured on this machine, 200,000 iterations: - `hpet`: **1522 ns** per call - `tsc`: **103 ns** per call Any application that queries time frequently pays ~15× more. In my case Thunderbird 155 became completely unusable — its UI thread issues ~21,000 `clock_gettime`/s and saturated a core, with menus refusing to open. The same Thunderbird on the same profile runs at ~10% CPU once the clocksource is `tsc`. Because the demotion is intermittent, the resulting symptom looks random and gets misattributed to whatever application happens to notice it first. **Workaround:** `tsc=reliable` on the kernel command line. After that the machine boots to `tsc` every time and the symptom is gone. **Suggestion:** The kernel's own message points at the BIOS, and that may well be correct — but this board's last BIOS is from 2022-12-14 and the vendor has published nothing since, so there is no firmware fix available. Given the CPU declares an invariant TSC, it may be worth either running the watchdog later in boot, or being less eager to demote on CPUs that advertise `constant_tsc` + `nonstop_tsc`. **System:** Ubuntu 24.04.4 · ASUS ROG STRIX G10DK, BIOS 310 (2022-12-14) · AMD Ryzen 7 5700G To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166715/+subscriptions