Ryzen 7 1700 random hard lockups, clean logs

W

whistle

New Member
May 10, 2026
2
1
3
Hi everyone,

I wanted to create a NAS using an old PC I had collecting dust. Here's what I have in it:

- Dell Inspiron 5675, Ryzen 7 1700, 16GB RAM
- LSI 9207-8i HBA (passthrough to truenas VM)
- RX580 GPU
- Realtek RTL8168h NIC - r8169 driver

Version: Proxmox VE 9.1.1, kernel 6.17.2-1-pve on Trixie

The PC is randomly freezing. I first noticed it when I left it on overnight. The display was still at the "Welcome to the Proxmox Virtual Environment" screen, but was completely frozen. All of the fans were still on. When I pinged the machine from my laptop, I would get "Destination Host Unreachable", the web UI couldn't connect.

The console freezes, network drops, and requires a hard reboot. It can happen anywhere from 10 minutes to several hours after boot. I haven't noticed a pattern.

- journalctl -b -1 has completely clean logs, no errors or warnings
- One time I did see: nft/ipset mutex deadlock and soft lockup CPU#4 ksmd but the other times I did not see that.
- I haven't seen any kernel panic captured by kdump
- No MCE errors

What I have done:
- I updated the BIOS to the latest version.
- I set kernel parameter: processor.max_cstate=5.
- Ran Memtest86 for one pass, no errors were found.

Has anyone else ever had this issue?
 
dcsapak said:
had a very similar issue on my (launch) ryzen 1700, tried some things from https://wiki.archlinux.org/title/Ryzen but in the end the only thing that solved it was to replace the cpu with something newer...
Click to expand...
After doing some more research, I found that first gen Ryzen CPUs have a hardware bug where it crashes when transitioning out of the C6 deep sleep state back into active state. The freezing was happening randomly and every time I checked the logs they were clean, so it was hard for me to understand what happened.

Anyways, the post I found on here had a link to a Github repo (https://github.com/r4m0n/ZenStates-Linux) and by running the command
python zenstates.py --c6-disable, it seems to have fixed the issue.

I now have over 22 hours of uptime as I write this. So far so good.

Edit:
I forgot to mention I also made it permanent by making sure MSR module loads on boot, which allows the script to write to the cpu registers. Then I added a crontab entry so the script runs automatically on boot. So it disables C6 state before anything else starts up
 
Last edited:
  • Like
Reactions: dcsapak
You must log in or register to reply here.
Top Bottom
Back