Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #59312
| From | Leon Meier <Leon.Meier@yandex.ru> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.kernel |
| Subject | Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored - (wild hack) shell script |
| Date | 2017-11-01 13:20 +0100 |
| Message-ID | <uH09Y-cD-1@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <uGjHJ-6Nr-33@gated-at.bofh.it> <uGDZL-2db-9@gated-at.bofh.it> <uGDZL-2db-7@gated-at.bofh.it> <uGjHJ-6Nr-33@gated-at.bofh.it> <uGDZL-2db-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
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.
Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored Leon Meier <Leon.Meier@yandex.ru> - 2017-10-30 16:00 +0100
Processed: Re: Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored owner@bugs.debian.org (Debian Bug Tracking System) - 2017-10-31 01:30 +0100
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored Ben Hutchings <ben@decadent.org.uk> - 2017-10-31 01:30 +0100
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored Leon Meier <Leon.Meier@yandex.ru> - 2017-10-31 11:20 +0100
Bug#880203: marked as done (After suspend&resume, cpufreq/scaling_max_freq is ignored) owner@bugs.debian.org (Debian Bug Tracking System) - 2017-10-31 11:40 +0100
Bug#880203: closed by Ben Hutchings <ben@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored) Leon Meier <Leon.Meier@yandex.ru> - 2017-10-31 13:40 +0100
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored - (wild hack) shell script Leon Meier <Leon.Meier@yandex.ru> - 2017-11-01 13:20 +0100
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored - (wild hack) shell script Ben Hutchings <ben@decadent.org.uk> - 2017-11-01 13:50 +0100
Bug#880203: closed by Ben Hutchings <ben@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored) Ben Hutchings <ben@decadent.org.uk> - 2017-11-01 13:50 +0100
Bug#880203: closed by Ben Hutchings <ben@decadent.org.uk> (Re: Fwd: Re: Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored) Leon Meier <Leon.Meier@yandex.ru> - 2017-11-01 14:00 +0100
Bug#880203: After suspend&resume, cpufreq/scaling_max_freq is ignored - alternative shell script Leon Meier <Leon.Meier@yandex.ru> - 2017-11-01 14:40 +0100
csiph-web