pn51: add TSC runtime switch test to next steps
Some checks failed
Run nix flake check / flake-check (push) Has been cancelled
Some checks failed
Run nix flake check / flake-check (push) Has been cancelled
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -67,7 +67,14 @@ These appear on both units and can be ignored:
|
|||||||
## Next Steps
|
## Next Steps
|
||||||
|
|
||||||
- Monitor both units for stability (fTPM disabled on both, BIOS updated on pn02)
|
- 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)
|
- **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:
|
||||||
- If freezes continue, try disabling unused hardware in BIOS (GPU, WiFi, Bluetooth, audio)
|
```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
|
- If still freezing, may be a hardware defect
|
||||||
- Once stable: add second RAM stick back to pn02, reinstall with NVMe
|
- Once stable: add second RAM stick back to pn02, reinstall with NVMe
|
||||||
|
|||||||
Reference in New Issue
Block a user