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