le9-patch VS ZenStates-Linux

Also, are you using a stock kernel? Try using this patchset https://github.com/hakavlad/le9-patch and more specifically set this

This kernel patch work really well: https://github.com/hakavlad/le9-patch/

Oh that’s a known problem. There are many patch sets floating around that fix it by triggering the OOM killer when the system is thrashing: https://github.com/hakavlad/le9-patch

I’ve never ran into this specific problem back when I was daily driving desktop Linux, but I did run into 1000 similar ones that needed bandaid solutions. It’s death of a thousand cuts: https://news.ycombinator.com/item?id=28490753

I actually do use the Zen kernel already. If you are already using the zen kernel , make sure to use the latest one which has le9 patches , imho this patch can Improve user experience in tight memory situations. Check this https://github.com/hakavlad/le9-patch, saw many people praise this , but ymmv. Best of luck

- Limit the amount of thrashing or protect some pages from being reclaimed. This has been proposed by Google first and several other people since then, but AFAIK it has never been implemented in the mainline kernel.

Regarding the latter solution, there is a patchset called le9-patch[1] that is included in some alternative Linux kernels and it should be relatively safe to use.

[1]: https://github.com/hakavlad/le9-patch

Patch i was talking about le9-patch. it's only a proof of concept with very rough edges, but consider it isn't written by an experienced kernel developer with deep knowledge of memory subsystem.

You can also use: https://github.com/r4m0n/ZenStates-Linux/tree/master

https://github.com/r4m0n/ZenStates-Linux/blob/master/zenstat...

Not sure if this is applicable to EPYC CPUs, probably not. But I would expect that it's possible to disable C6 in some similar way on EPYC CPUs without rebooting the system. (If you are actually at risk of running into this issue, you likely don't want to reboot the system…)

I tried everything you've mentioned but finally fixed the issue on my 1300 using python zenstates. I had it run on boot with this systemd service: ``` [Unit] Description=Disable C6 state on ryzen processor to fix idle freezing

The freezing has only occurred when idle so far: when the monitor returns from sleep, no signal is returned. A related bug report references this Python script several times in the comments, and there's also another for Go. No commits in several years, sudo is obviously required and I don't know if they can be considered as safe.

Note: I merely added the systemd script (IIRC by reusing some forum messages while digging my crashes) + the debian packaging. That's not my script :), credit for this script goes to https://github.com/r4m0n/ZenStates-Linux

I fixed this by toggling some power management option (can't remember which one, deep in a submenu) in UEFI, then checking with https://github.com/r4m0n/ZenStates-Linux. It must return C6 disabled for package, enabled for cores. Ryzen 5 1600

Also try disabling C6 sleep with zenstates

You can undervolt by manipulating the VIDs with zenstates https://github.com/r4m0n/ZenStates-Linux

It's the Ryzen bug. You need to disable your C6 cpu state (https://github.com/r4m0n/ZenStates-Linux), disable dram power down enable(bios option) and set Power Supply Idle Control to Typical Current Idle(bios option)

So the other hand is zenstates.py It pokes a register to keep C6 power state from happening. I launch on reboot, and my machine no longer has sleep state problems.