earlyoom VS ZenStates-Linux

> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.

I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.

> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.

Yeah. Exactly. But as the thread says, why aren't those things set up automatically?

It's not that simple: some defaults may differ, and some features may arrive at different times (if ever). For example, earlyoom has been enabled on Workstation since F32, but the KDE Plasma spin got it one release later.

Most answers will answer your question, but you can do better and avoid the freezes in the first place. IME almost every time the system froze up and didn't come back in a few seconds it was out of memory. The obvious solution is to add memory, but you can use Early OOM to kill hungry processes if you're running out of memory instead.

It sounds like you're running out of memory though, so if your OS's OOM killer isn't working as well as it should, you can try earlyoom as an alternative.

Swap is indeed supposed to prevent this AFAIK. You can though try some tools like EarlyOOM and see if it helps : https://github.com/rfjakob/earlyoom

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.