Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored - (wild hack) shell script

[Leon Meier <Leon.Meier@yandex.ru>]

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.