From 5346889b738e868a731f37941ac580f1884aefc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torjus=20H=C3=A5kestad?= Date: Sun, 22 Feb 2026 11:50:30 +0100 Subject: [PATCH] pn51: add TSC runtime switch test to next steps Co-Authored-By: Claude Opus 4.6 --- docs/plans/pn51-stability.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/plans/pn51-stability.md b/docs/plans/pn51-stability.md index 268c644..7c29fee 100644 --- a/docs/plans/pn51-stability.md +++ b/docs/plans/pn51-stability.md @@ -67,7 +67,14 @@ These appear on both units and can be ignored: ## Next Steps - Monitor both units for stability (fTPM disabled on both, BIOS updated on pn02) -- If either freezes again, try adding `tsc=unstable` kernel parameter (unlikely to help but easy to rule out) -- If freezes continue, try disabling unused hardware in BIOS (GPU, WiFi, Bluetooth, audio) +- **Test TSC stability after boot**: The TSC skew may only occur during early boot (power state transitions, frequency scaling) and stabilize later. Test by switching clocksource back to TSC at runtime: + ```bash + # Check current clocksource + cat /sys/devices/system/clocksource/clocksource0/current_clocksource + # Switch back to TSC (kernel watchdog will revert if skew persists) + echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource + ``` + If TSC stays stable after boot, this is just an early-boot calibration issue. This matters for virtualization performance — HPET is 50-100x slower than TSC per timing call, and KVM guests rely on the host clocksource. +- If either freezes again, try disabling unused hardware in BIOS (GPU, WiFi, Bluetooth, audio) - If still freezing, may be a hardware defect - Once stable: add second RAM stick back to pn02, reinstall with NVMe