Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored - alternative shell script

One can also sidestep writing to /tmp in the script in /lib/systemd/system-sleep/: #!/bin/bash ### Ensure that the frequency is restored upon resuming from suspend # The array to store frequencies: declare -a frequencies # Number of processors minus 1: N=$((`nproc --all`-1)) case "${1}" in

Bug#880203: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored)

On 01.11.2017 13:38, Ben Hutchings wrote: On Tue, 31 Oct 2017 13:25:11 +0100 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

Bug#880203: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored)

On Tue, 31 Oct 2017 13:25:11 +0100 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? The driver does

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

On Wed, 2017-11-01 at 13:02 +0100, Leon Meier wrote: > 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 >

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

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

Bug#880203: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored)

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?

Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored

tags 880203 - moreinfo thanks Ben, thank you for the clarification. On 31.10.2017 00:35, Ben Hutchings wrote: Control: tag -1 moreinfo If this system has an Intel CPU, I'm afraid this is expected behaviour. They no longer allow the OS to set an exact frequency, only a 'P- state'

Processed: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored

Processing commands for cont...@bugs.debian.org: > tags 880203 - moreinfo Bug #880203 [linux-image-4.9.0-4-amd64] After suspend, cpufreq/scaling_max_freq is ignored Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 880203:

Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored

Control: tag -1 moreinfo If this system has an Intel CPU, I'm afraid this is expected behaviour. They no longer allow the OS to set an exact frequency, only a 'P- state' (performance level). The Linux cpufreq driver for these processors (intel_pstate) translates the requested frequency into a

Processed: Re: Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored

Processing control commands: > tag -1 moreinfo Bug #880203 [linux-image-4.9.0-4-amd64] After suspend, cpufreq/scaling_max_freq is ignored Added tag(s) moreinfo. -- 880203: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880203 Debian Bug Tracking System Contact ow...@bugs.debian.org with

Bug#880203: After suspend, cpufreq/scaling_max_freq is ignored

Package: linux-image-4.9.0-4-amd64 Version: 4.9.51-1 To avoid fan noise, I set up my laptop such that it sets a low CPU frequency upon boot via for i in `seq 0 7`; do echo 120 > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done in a startup script. This all goes well until