More power sleep Linux stuff – or how to set permissions to make a keystroke out of it

This command does successfully put the computer to sleep (and thus the screens eventually go dark and no longer light up the room like stadium lighting):

echo freeze > /sys/power/state

But mere mortals don’t have permission to do that.

I added a script in /etc/init.d which does a chmod 666 /sys/power/state on startup (see the previous post about editing /etc/init.d/after.local)

Credit where credit is due: a gentleman named Aaron Ball posted this at his web site oper.io – clever logo, too, to combine the power switch icon as “.io” – but I digress.

Then another tiny script that simply does the echo command for me:

#!/bin/sh
/usr/bin/echo freeze > /sys/power/state

I had started to go down the road of a sudoers file entry, which would give anyone permission to run this script; but the problem isn’t who runs the command. The problem is that the target of the echo command, /sys/power/state, isn’t going to allow writing by a script (even if run by sudo).

Last step was to add a keystroke to my KDE shortcuts. System Settings –> Custom Shortcuts –> Edit –> New –> Global Shortcuts

Name the action, assign the keystrokes to invoke it, and make the action the tiny script above. Works like a charm. 🙂

AMD Ryzen 1700 and power sleep failure

I had bought all the parts for a new system at the end of 2017, and was mostly happy with it. The motherboard was an AS Rock Taichi and the CPU was an AMD Ryzen 1700. I bought the highest MHz AMD Ryzen I could get except I avoided the 220 Watts TDP; power draw on this chip is about 65 Watts TDP.

Certainly, I was thrilled with system performance, and very reasonable price. But sleep states were a problem. The system would go so deep into sleep, it would never wake up. I would have to press and hold the power switch to get it back: not good. Once in a while, the box would freeze hard too; usually while scrolling a Facebook page. So I had this sense of unease that I’d made a mistake buying the AS Rock Taichi X370 and trying to run Linux on it.

This last birthday, I bought myself a replacement motherboard: an MSI X470 Gaming Plus. I spent my birthday pulling out the Taichi motherboard and putting in the 470GP.

And my ACPI sleep problems did not go away. Rats!

I’ve taken some vacation time, and looking through the log files, I did find an error message that lead me to some vital information. The AMD Ryzen 1700 has an ACPI sleep state – C6 – which Linux doesn’t play nice with. A patch was offered to the Linux maintainers, but not accepted. I don’t know why, and I’m not sure it matters, either.

But what someone did, is make a Python script that pokes and prods the correct bits in the Ryzen 1700 to have it declare that ACPI sleep state C6 is not available / should not be used.

I haven’t had a sleep state problem with this rig since. 😀

First, I needed this: Github ZenStates. I saved this script as /home/myhomelocation/zenstates.py

Then I needed two bash scripts to run it after system startup:

/etc/init.d/after.local

which contains (and is executable):

#!/bin/sh
/etc/init.d/set_c6_acpi_state_disabled.sh

/etc/init.d/set_c6_acpi_state_disabled.sh

which contains (and is executable):

#!/bin/sh
# ScriptName=set_c6_acpi_state_disabled
/usr/bin/python /home/myhomelocation/zenstates.py --c6-disable

In theory, this could be a single script: after.local could be the script to run the Python script zenstates.py. But what if I find I want more than one script to run after system startup? This way, I just add another line to after.local

This week I talked with my brother, who found a relevant piece of information (while researching something else). Apparently AMD will give me a new CPU that doesn’t have this problem, as a warranty repair. So I guess this is AMD being honorable enough to admit they made a mistake here; that is nice. The caveat is, they cannot trust people to not fry their CPU and use this as an excuse to get a replacement under warranty. So the drill becomes: get an RMA from AMD, remove the Ryzen 1700, ship it (at my cost) to them, they test the CPU to make sure it’s not fried (is otherwise good except for the C6 power state problem), and then they ship a replacement. Total turnaround time is probably one month.

Do I want this, my main system, to be down for a month until the AMD CPU RMA SOP EOP FTW? The warranty on the CPU is three years, and I bought it two and a quarter ago.

I think I’m good, with just a software patch. I’m just happy that r4m0n found and supplied a patch.

Thank you r4m0n. 🙂