proxmox freeze di ryzen lama: fix yg keliatan gagal

Mini PC proxmox gw mulai freeze tiap beberapa jam. Lampu power tetap nyala, tapi SSH, web UI, bahkan ping berhenti jawab. Cuma hard power cycle yg bisa balikin mesinnya.

Boot sebelumnya ga punya panic atau shutdown trail. Journal-nya berhenti begitu aja di tengah baris biasa.

Gejalanya ngarah ke masalah C-state yg terkenal di Ryzen generasi awal. Gw pasang kernel workaround, reboot, lalu liat box-nya mati lagi tiga setengah menit kemudian.

Ternyata kejadian terakhir itu bukan freeze. Satu observasi yg salah bikin sisa diagnosis gw belok ke arah lain.

Mesinnya

Host-nya Lenovo m715q Tiny dengan Ryzen 5 2400GE generasi Raven Ridge dan RAM 30 GB. Proxmox jalan headless dengan satu VM buat zigbee2mqtt dan dongle USB Zigbee Sonoff yg di-passthrough ke guest.

Setup ini stabil berbulan-bulan sebelum freeze mulai muncul.

Baca crash yg ga punya crash log

Kalo kernel wedge total, ga ada yg bisa dicek saat kejadian. Bukti yg tersisa cuma journal dari boot sebelumnya.

Gw mulai dari boot history:

journalctl --list-boots

Lalu gw cek cara boot sebelumnya berakhir:

journalctl -b -1 -n 10 --no-pager

Shutdown bersih berakhir dengan systemd-shutdown, reboot:, atau sequence lain yg rapi. Boot yg bermasalah berhenti mendadak di baris log yg ga nyambung.

Itu bukti mesinnya ga shutdown dengan benar. Bukan bukti penyebabnya. Kernel freeze sama listrik putus ninggalin journal yg sama-sama kepotong.

Pembeda itu awalnya kelewat sama gw.

Tersangka pertama: deep C-state

Ryzen generasi awal punya masalah waktu CPU masuk deep idle state lalu gagal bangun lagi. Gejala luarnya cocok banget: power tetap nyala, sistem ga jawab, dan ga ada error terakhir yg sempat ditulis ke disk.

Workaround umumnya adalah ngebatesin idle state terdalam. Mesin ini boot lewat grub dengan root filesystem di LVM, jadi gw ubah /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1 idle=nomwait"

Lalu generate ulang config grub:

update-grub

Setelah reboot, /proc/cmdline mastiin dua parameter tadi aktif:

cat /proc/cmdline
# ...quiet processor.max_cstate=1 idle=nomwait

Tiga setengah menit kemudian, mesinnya kehilangan power. Journal barunya berhenti mendadak, sama kayak freeze sebelumnya.

Gw anggap itu bukti workarounds-nya gagal. Padahal engga…

Baris log terakhir bukan penyebabnya

Setelah C-state gw coret, log punya satu tersangka yg keliatannya jelas. Tiap boot yg gagal berhenti di sekitar message ini:

VM 100 qga command failed - guest-ping timeout

VM Zigbee langsung keliatan bersalah.

Proxmox nulis message itu tiap beberapa detik karena guest agent-nya ga jalan. Kalo mesin berhenti di waktu random, baris yg paling sering ditulis punya kemungkinan paling besar buat muncul terakhir.

Ini sampling artifact, bukan causal signal.

Check lainnya juga bersih:

• VM pakai USB passthrough, bukan PCI atau GPU passthrough
• USB reset cocok dengan momen guest ngambil alih dongle
• ga ada amdgpu hang di boot mana pun
• ga ada error OOM, MCE, EDAC, atau ZFS
• RAM 30 GB cuma kepakai 6 GB

Ga ada bukti yg dukung masalah di guest, GPU, memory pressure, atau storage.

Tren meyakinkan dari data yg salah

Uptime sebelum tiap kejadian keliatan makin pendek:

2 hari -> 14 jam -> 47 menit -> 3.5 menit

Sequence yg makin cepat itu bikin kerusakan hardware keliatan masuk akal. Host-nya pakai dua DIMM 16 GB beda merek, Samsung sama Hynix, non-ECC, dan jalan di 1333 MHz. Thermal, RAM, sama power delivery langsung masuk daftar tes berikutnya.

Sebelum bongkar box, gw aktifin hardware watchdog di /dev/watchdog0 supaya kernel wedge berikutnya bisa auto-reboot. Setelah itu mesinnya gw tinggal semalaman.

Besoknya masih nyala. Besoknya lagi juga masih nyala. Freeze-nya ga pernah balik.

Workaround C-state ternyata udah efektif dari reboot pertama.

Kejadian tiga setengah menit itu listrik putus. Gw sendiri salah matiin saklar di power strip.

Karena journald ga bisa bedain itu dari hard freeze, gw masukin event-nya ke timeline sebagai failure baru. Satu titik palsu bikin fix yg stabil keliatan rusak dan ngubah sequence random jadi tren hardware yg meyakinkan.

Batas dari bukti yg ada

Journal yg kepotong membuktikan unclean stop. Dia ga bisa bedain kernel freeze sama listrik putus.

Baris log terakhir cuma nunjukin apa yg terakhir sempat ditulis. Dia ga otomatis nunjukin penyebab host berhenti.

Interval failure yg makin pendek bisa mendukung hipotesis hardware, tapi cuma kalo semua titik ngejelasin event yg sama. Punya gw engga.

Buat host Ryzen generasi awal yg freeze tanpa log, processor.max_cstate=1 idle=nomwait masih layak jadi tes pertama. Pastikan parameternya masuk ke /proc/cmdline, lalu nilai cuma freeze yg bener-bener terverifikasi setelah reboot itu.

Workaround-nya langsung benerin host gw. Buktinya sempat keliatan beda karena satu power cut gw kasih label failure.