On 31.10.2017 13:25, Leon Meier wrote:
On 31.10.2017 11:39, Debian Bug Tracking System wrote:
Yes, but that doesn't mean we can do anything about it.
Why not simply re-issue the request setting the performance-level after
resume?
You could at least suggest a script similar to the following one to be
added to /lib/systemd/system-sleep.
#!/bin/sh
### Ensure that the frequency is stored/restored upon resume
case "${1}" in
pre)
# Store the old frequency
for i in `seq 0 7`; do cat
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq >
/tmp/scaling_max_freq$i; done
;;
post)
# Wild hack: insert a junk value first
for i in `seq 0 7`; do echo 999999999999999 >
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done
# Set the old frequency
for i in `seq 0 7`; do
cat /tmp/scaling_max_freq$i >
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq
rm -f /tmp/scaling_max_freq$i;
done
;;
esac
Exercise for the reader: automatically determine the number of CPUs,
ensure that created files have fresh names, that there is sufficient
unused space in /tmp, and that proper error handling is done if it is
not the case.
However, really, this is much better done in the kernel manipulating
p-states directly rather than through the overkill of wild hacks and
invoking a shell script modifying various places in the file system.
