Bug 1374212
| Summary: | [Regression] "/usr/bin/cpupower frequency-set -u" no longer has any effect on CPU clock rates | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Julian Seward <jseward> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 23 | CC: | dwt, gansalmon, ichavero, itamar, jonathan, jseward, kernel-maint, labbott, madhu.chinakonda, mchehab | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | kernel-4.7.4-200.fc24 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-09-23 00:23:33 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Julian Seward
2016-09-08 09:20:36 UTC
Was the 4.7 series the first one where this stopped working? Is the command returning successfully? (Do echo $? right after the cpupower command). (In reply to Laura Abbott from comment #1) > Was the 4.7 series the first one where this stopped working? I wondered that too. I rebooted yesterday into a 4.6.x kernel (two updates previous to this one) and tried there, and it didn't work there either. So I was mystified and wondered if I'd done something wrong. For sure the command worked successfully for several months up until a couple of weeks back. > Is the command returning successfully? (Do echo $? right after the cpupower > command). Yes, it is (assuming 0 == success in this case): [root@dundee ~]# /usr/bin/cpupower frequency-set -u 2510MHz ; echo $? ; grep MHz /proc/cpuinfo 0 cpu MHz : 2900.000 cpu MHz : 2903.540 cpu MHz : 2808.843 cpu MHz : 2900.000 I should perhaps mention, don't read too much into the "two weeks" timespan. I noticed that the command had stopped working earlier this week, and I know it worked about two weeks ago. In that two week period I did "dnf update" a couple of times, and hadn't done so for probably a month prior to that. So the "two weeks" is pretty approximate. It sounds like the time frame isn't very useful for bisecting but I was mostly curious if this was a 4.7 regression but it sounds like it isn't. The cpupower binary is mostly a wrapper around some sysfs files, can you check the sysfs files manually? cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq for all cpus Hmm, they are all set at the max value (3.9 GHz) and "cpupower frequency-set" doesn't change them: [root@dundee ~]# /usr/bin/cpupower frequency-set -u 2510MHz [root@dundee ~]# [root@dundee ~]# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq 3900000 3900000 3900000 3900000 [root@dundee ~]# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq 3900000 3900000 3900000 3900000 -r--r--r--. 1 root root 4096 Sep 8 10:49 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq -rw-r--r--. 1 root root 4096 Sep 8 21:04 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -r--r--r--. 1 root root 4096 Sep 8 21:04 /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq -rw-r--r--. 1 root root 4096 Sep 8 15:02 /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq -r--r--r--. 1 root root 4096 Sep 8 21:04 /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq -rw-r--r--. 1 root root 4096 Sep 8 15:02 /sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq -r--r--r--. 1 root root 4096 Sep 8 21:04 /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq -rw-r--r--. 1 root root 4096 Sep 8 15:02 /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq I could strace "cpupower frequency-set" to see if it actually tries to write to them. From a first glance, though, it doesn't. Can you attach an strace log? I notice when I run it on my system there is a message about setting cpus # /usr/bin/cpupower frequency-set -u 2510MHz Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 Setting cpu: 3 Setting cpu: 4 Setting cpu: 5 Setting cpu: 6 Setting cpu: 7 but I don't see that on your output there which makes me think something isn't detecting the topology correctly. While I'm thinking about it, can you share your systemlog (journalctl) as well? This could be selinux related. Created attachment 1199281 [details]
strace log for "/usr/bin/cpupower frequency-set -u 2510MHz"
I notice that /sys/devices/system/cpu/cpu0/online doesn't exist, but
the corresponding files for cpus 1,2,3 do exist.
Note also, this is a 4 core, 8 thread cpu. The reason it only reports
4 cpus is because, having lost the ability to control fan noise by setting
the max clock rate, I disabled hyperthreading in the bios in an attempt
to reduce the cpu's max power consumption.
Created attachment 1199282 [details]
Output of "journalctl -e --no-pager"
I have a cron job that runs "/usr/bin/cpupower frequency-set -u 2510MHz"
once a minute, as is visible from the log. It seemed like the easiest way
to reliably get the clock rate limited across suspend/resume.
I reviewed the logs and the code. It turns out there was a bug when converting to new APIs so code was erroring out early. My rawhide system showed the same behavior so I wrote a patch and submitted it upstream. We'll see what the maintainers say. Ah, good that you found the root cause. In the meantime, per your comments above, I can work around it thusly: echo 2510000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq It seems that it is only necessary to set the freq for cpu0, since whatever limit I set for cpu0 appears to apply to all the other cores too. Thank you for looking into this so soon after I filed it. Please be aware that currently 'cpupower frequency-set' appears unable to set the governor as well. I can 'cpupower frequency-set -g conservative' and get a zero return code, but the governor is still the default ondemand according to 'cpupower frequency-info'. However, setting the governor using the cpufreq applet in the mate panel works, and my choice of governor is then correctly reported by frequency-info. Of course, it doesn't persist across reboots. There was an update about ten days ago which seemed to break a lot of things. For a while, the cpufreq applet wouldn't render in the panel at all, but yesterday's update of the mate-applet's package fixed that. kernel-4.7.4-200.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bc436ff4fd kernel-4.7.4-100.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-eccc31a322 kernel-4.7.4-100.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-eccc31a322 kernel-4.7.4-200.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bc436ff4fd kernel-4.7.4-200.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. kernel-4.7.4-100.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |