Files

Run nix flake check / flake-check (push) Has been cancelled

Details

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-02-22 11:50:30 +01:00

ASUS PN51 Stability Testing

Overview

Two ASUS PN51-E1 mini PCs (Ryzen 7 5700U) purchased years ago but shelved due to stability issues. Revisiting them to potentially add to the homelab.

pn01: Would boot but freeze randomly after some time. No console errors, completely unresponsive. memtest86 passed.
pn02: Had trouble booting — would start loading kernel from installer USB then instantly reboot. When it did boot, would also freeze randomly.

Disabled fTPM (labeled "Security Device" in ASUS BIOS) on both units
- AMD Ryzen 5000 series had a known fTPM bug causing random hard freezes with no console output
- Both units booted the NixOS installer successfully after this change
Installed NixOS on both, added to repo as pn01 and pn02 on VLAN 12
Configured monitoring (node-exporter, promtail, nixos-exporter)

pn02 froze approximately 1 hour after boot
All three Prometheus targets went down simultaneously — hard freeze, not graceful shutdown
Journal on next boot: system.journal corrupted or uncleanly shut down
Kernel warnings from boot log before freeze:
- TSC clocksource unstable: Marking clocksource 'tsc' as unstable because the skew is too large — TSC skewing ~3.8ms over 500ms relative to HPET watchdog
- AMD PSP error: psp gfx command LOAD_TA(0x1) failed and response status is (0x7) — Platform Security Processor failing to load trusted application
pn01 did not show these warnings on this particular boot, but has shown them historically (see below)

Checked kernel logs after ~9 hours uptime — both units still running
pn01 now shows TSC unstable and PSP LOAD_TA failure on this boot (same ~3.8ms TSC skew, same PSP error)
pn01 had these same issues historically when tested years ago — the earlier clean boot was just lucky TSC calibration timing
Conclusion: TSC instability and PSP LOAD_TA are platform-level quirks of the PN51-E1 / Ryzen 5700U, present on both units
The kernel handles TSC instability gracefully (falls back to HPET), and PSP LOAD_TA is non-fatal
Neither issue is likely the cause of the hard freezes — the fTPM bug remains the primary suspect

These appear on both units and can be ignored:

clocksource: Marking clocksource 'tsc' as unstable — TSC skew vs HPET, kernel falls back gracefully. Platform-level quirk on PN51-E1, not always reproducible on every boot.
psp gfx command LOAD_TA(0x1) failed — AMD PSP firmware error, non-fatal. Present on both units across all BIOS versions.
pcie_mp2_amd: amd_sfh_hid_client_init failed err -95 — AMD Sensor Fusion Hub, no sensors connected
Bluetooth: hci0: Reading supported features failed — Bluetooth init quirk
Serial bus multi instantiate pseudo device driver INT3515:00: error -ENXIO — unused serial bus device
ata2.00: supports DRM functions and may not be fully accessible — Samsung SSD DRM quirk (pn02 only)

Monitor both units for stability (fTPM disabled on both, BIOS updated on pn02)
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:
```
# 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