Bugzilla – Bug 119836
CPU politics not applied
Last modified: 2006-04-20 13:09:43 UTC
Despite I have set CPU for performance to maximum power (1600Mhz), it's stil at its lowest frequency (600Mhz). Moreover, plug/unplug takes plenty of seconds to notice in kpowersave.
Created attachment 51313 [details] /etc/sysconfig/powersave
Created attachment 51314 [details] /var/log/messages
It is Dell D600 btw. bash# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1600MHz stepping : 5 cpu MHz : 598.119 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2 bogomips : 1197.23
After few attempts like: echo -n 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed reboot helped.
Michal, which version of powersave and hal did you use?
Just what's in SL10.0: powersave-0.10.15-5 hal-0.5.4-6
There is a hal bug(117964) which prevents the powersave daemon to get noticed of acpi events like ac adater plug/unplug). A you update package will be prepared soon. Regarding the cpu policy issue, can you try using the userspace governor for cpufreq --> CPUFREQ_CONTROL="userspace" in /etc/sysconfig/powersave/cpufreq. Empty means default which is kernel.
Well I already tried (see comment #4): echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo -n 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed And the system was still running at 600MHz.
Maybe Thomas has an idea?
Maybe your machine runs too hot? You might like to watch min/max freq, temperature and your *passive trip point limit* with (concatenated without line breaks): watch -n1 cat /proc/acpi/thermal_zone/*/temperature /proc/acpi/thermal_zone/*/trip_points /sys/devices/system/cpu/cpu0/cpufreq/scaling_* If the machine is powered off (cold for while), and runs with 1600 in the beginning, then getting slower, it's probably this. Maybe we still have a bug there and the frequency does not come up again after it reached the lowest freq?!?
bash$ cat ... temperature: 32 C critical (S5): 102 C 1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 ondemand userspace powersave performance 600000 centrino performance 600000 600000 I don't think it's related to temperature, it seems to be related to suspend/resume cycles, along with combination with power supply plug/unplug. If I S/R with always running on power supply attached, it's OK. It seems like if I unplug it first, it won't come back. I'll try that again, however, you have the same machine, so might try that too ...
OK, not related to suspend/resume, the CPU is not returned to correct state after re-plug of the power cable. # clean system, power cable plugged in, after reboot temperature: 39 C critical (S5): 102 C 1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 ondemand userspace powersave performance 1600000 centrino performance 1600000 600000 # cable unplugged temperature: 36 C critical (S5): 102 C 1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 ondemand userspace powersave performance 600000 centrino ondemand 600000 600000 # cable re-plugged temperature: 34 C critical (S5): 102 C 1600000 1600000 1600000 1400000 1200000 1000000 800000 600000 ondemand userspace powersave performance 600000 centrino performance 600000 600000 This basically renders the laptop almost unusable, does it work on other systems correctly?
Anything I could try next? The notebook is basically unusable after unplug/replug, this is really annoying ...
Following comment #8, this isn't most likely a powersave issue, seems rather like a kernel problem.
cpufreq works OK, as long as you don't un(/re-)plug the AC adapter? Do you have an option in BIOS for speedstep to be lowered on battery? If yes better disable this (set to something like automatic for both: AC and battery). You could also try ec_burst=0? If nothing helps, please tell me a time when I could access the machine again and you can (un-)plug the AC adapter.
What exactly you mean with "cpufreq works OK, as long as you don't un(/re-)plug the AC adapter?"? I haven't changed anything in BIOS since I updated 9.3 to 10.0, so unless something changed in linux, it shouldn't have any effect.
> cpufreq works OK, as long as you don't un(/re-)plug the AC adapter? -> You are able to switch frequencies (or it is done automatically according to the CPU load) as long as you do not (un-)plug the AC adapter? Have you tried ec_burst=0 boot param? When I logged into your machine everything seemed to work fine. Tell me and we could do it again, but you have to (un-)plug the power cable if this is the only way to reproduce that.
> You are able to switch frequencies (or it is done automatically according to > the CPU load) as long as you do not (un-)plug the AC adapter? I do not use cpufreq when running on AC, will test that. > Have you tried ec_burst=0 boot param? Not yet (I need that notebook for work now :-). Will try that too.
So ec_burst=0 doesn't help either. > You could try to: stop powersaved, hal, acpid services and do a: > cat /proc/acpi/event ac_adapter AC 00000080 00000000 processor CPU0 00000080 00000007 battery BAT0 00000080 00000001 ac_adapter AC 00000080 00000001 processor CPU0 00000080 00000002
Danny Kukawka wrote also: > After a clean reboot with AC Online all work correct. But if you unplug and > replug the AC the cpufreq never change again with powersave. > > The problem with kernel-ondemand-gov.: scaling_min_freq and scaling_max_freq > are both on 600000 . He has the same Dell D600 as I have, so it might be possible for you to debug it locally.
*** Bug 131320 has been marked as a duplicate of this bug. ***
So any news on this?
So anything new? This is *really* annoying :-(
IMO Thomas worked on this issue yesterday, but he is atm in vacation.
OK, thanks for the notice!
BTW I found an interesting thing: if I put the system under load, it switches to 1600. If still under load I unplug the cable, the frequency is kept at 1600. But when I replug the cable again, the frequency decreases to 600 despite still being under high load.
So, any news on this?
Sorry, holidays and I couldn't find it yet ... Venkatesh: I expect that to be in the deeps of the speedstep-centrino driver itself (assumption!). Let me explain the problem again, so that you do not need to reread the whole bug: This laptop limits its CPU frequencies when working on battery. The cpufreq core driver seem to notice the change correctly (not sure whether it remembers the last set value correct, but I expect it... at least the thermal limits work the same way and work nicely) and the freq-table is limited to the one (lowest) freq (see the: "verification lead to (600000 - 600000 kHz)" message in the debug output below). What I watched is a kind of delay until the change of cpufreq limit gets activated. E.g. unplugging the AC cable, the speed is still set to Max (in the debug log below e.g. for 20 secs) until it really gets lowered, but the limits in the freq-tables is already set to only allow the lowest freq. Vice versa it seems to happen, if plugging AC adapter in, that still only 600 MHz are set (even freq-core limits are correct and already allow all frequencies). The frequency can be forced to go up after some time by manually echoing higher frequencies to .../scaling_setspeed, but this should not be necessary... the userspace governor should not be involved in cpufreq limits (by thermal or CPU event cause) at all? What I think one problem is, is that the MSR register itself seem to be set to 600 MHz (value: 610), but the CPU itself is still running at 1700 MHz (not sure whether this is even possible ?!?). See this line in the log: speedstep-centrino: no change needed - msr was and needs to be 610.At this point I think the system is still running at 1700 Mhz, even MSR says (or centrino module thinks) it is already running at 600 MHz. Maybe therefore the buffered value that needs to be reset when the frequencies are not limited anymore is somehow lost? Here are the logs (### is an additional comment from me...): Nov 15 19:18:58 linux root: XXXXXXXXXXXXXXXXXXXX ### Plugging AC_adapter out -> running on battery -> frequency gets limited Nov 15 19:19:05 linux kernel: printk: 1 messages suppressed. Nov 15 19:19:05 linux kernel: cpufreq-core: updating policy for CPU 0 Nov 15 19:19:05 linux kernel: cpufreq-core: setting new policy for CPU 0: 600000 - 1700000 kHz Nov 15 19:19:05 linux kernel: freq-table: request for verification of policy (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:05 linux kernel: freq-table: verification lead to (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:05 linux kernel: freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0 Nov 15 19:19:05 linux kernel: freq-table: verification lead to (600000 - 600000 kHz) for cpu 0 Nov 15 19:19:05 linux kernel: cpufreq-core: new min and max freqs are 600000 - 600000 kHz Nov 15 19:19:05 linux kernel: cpufreq-core: governor: change or update limits Nov 15 19:19:05 linux kernel: cpufreq-core: __cpufreq_governor for CPU 0, event 3 Nov 15 19:19:05 linux kernel: userspace: limit event for cpu 0: 600000 - 600000 kHz, currently 1700000 kHz, last set to 1700000 kHz Nov 15 19:19:05 linux kernel: cpufreq-core: target for CPU 0: 600000 kHz, relation 1 Nov 15 19:19:05 linux kernel: freq-table: request for target 600000 kHz (relation: 1) for cpu 0 Nov 15 19:19:05 linux kernel: freq-table: target is 7 (600000 kHz, 1552) Nov 15 19:19:05 linux kernel: speedstep-centrino: no change needed - msr was and needs to be 610 ### The above line seems to be wrong, CPU freq still at 1700? At least ### scaling_setspeed says so. Nov 15 19:19:08 linux root: XXXXXXXXXXXXXXXXXXXX ### Plugging AC adapter in again -> all frequencies allowed -> speed must go up Nov 15 19:19:21 linux kernel: cpufreq-core: updating policy for CPU 0 Nov 15 19:19:21 linux kernel: cpufreq-core: setting new policy for CPU 0: 600000 - 1700000 kHz Nov 15 19:19:21 linux kernel: freq-table: request for verification of policy (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:21 linux kernel: freq-table: verification lead to (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:21 linux kernel: freq-table: request for verification of policy (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:21 linux kernel: freq-table: verification lead to (600000 - 1700000 kHz) for cpu 0 Nov 15 19:19:21 linux kernel: cpufreq-core: new min and max freqs are 600000 - 1700000 kHz Nov 15 19:19:21 linux kernel: cpufreq-core: governor: change or update limits Nov 15 19:19:21 linux kernel: cpufreq-core: __cpufreq_governor for CPU 0, event 3 Nov 15 19:19:21 linux kernel: userspace: limit event for cpu 0: 600000 - 1700000 kHz, currently 1700000 kHz, last set to 1700000 kHz Nov 15 19:19:21 linux kernel: cpufreq-core: target for CPU 0: 1700000 kHz, relation 0 ### Yes, we want to have 1700 MHz again. Nov 15 19:19:21 linux kernel: freq-table: request for target 1700000 kHz (relation: 0) for cpu0 ### Yes, we want to have 1700 MHz again. Nov 15 19:19:21 linux kernel: freq-table: target is 7 (600000 kHz, 1552) ### ?!? What the hell..., we want to have 1700 MHz ... Nov 15 19:19:21 linux kernel: speedstep-centrino: target=1700000kHz old=1700000 new=600000 msr=0610 ### Target seem to be OK, what is the difference between target and new? ### New is wrong? Nov 15 19:19:21 linux kernel: cpufreq-core: notification 0 of frequency transition to 600000 kHz Nov 15 19:19:21 linux kernel: userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz Nov 15 19:19:21 linux kernel: cpufreq-core: notification 1 of frequency transition to 600000 kHz Nov 15 19:19:21 linux kernel: cpufreq-core: scaling loops_per_jiffy to 2394454 for frequency 600000 kHz Nov 15 19:19:21 linux kernel: userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz ### Above is wrong, speed must be set to 1700 again. Is this a following up ### error of above? Normally the userspace values get buffered and if the limit ### does not exist anymore, the speed should go up again without any userspace ### action required. Nov 15 19:19:24 linux root: XXXXXXXXXXXXXXXXXXXX ### manually echoing 1700 Mhz to scaling_setspeed -> this works ... Nov 15 19:31:44 linux kernel: cpufreq-core: setting new policy for CPU 0: 600000 - 1700000 kHz Nov 15 19:31:44 linux kernel: freq-table: request for verification of policy (600000 - 1700000 kHz) for cpu 0 Nov 15 19:31:44 linux kernel: freq-table: verification lead to (600000 - 1700000 kHz) for cpu 0 Nov 15 19:31:44 linux kernel: freq-table: request for verification of policy (600000 - 1700000 kHz) for cpu 0 Nov 15 19:31:44 linux kernel: freq-table: verification lead to (600000 - 1700000 kHz) for cpu 0 Nov 15 19:31:44 linux kernel: cpufreq-core: new min and max freqs are 600000 - 1700000 kHz Nov 15 19:31:44 linux kernel: cpufreq-core: governor switch Nov 15 19:31:44 linux kernel: cpufreq-core: __cpufreq_governor for CPU 0, event 2 Nov 15 19:31:44 linux kernel: userspace: managing cpu 0 stopped Nov 15 19:31:44 linux kernel: cpufreq-core: __cpufreq_governor for CPU 0, event 1 Nov 15 19:31:44 linux kernel: performance: setting to 1700000 kHz because of event 1 Nov 15 19:31:44 linux kernel: cpufreq-core: target for CPU 0: 1700000 kHz, relation 1 Nov 15 19:31:44 linux kernel: freq-table: request for target 1700000 kHz (relation: 1) for cpu0 Nov 15 19:31:44 linux kernel: freq-table: target is 1 (1700000 kHz, 4401) Nov 15 19:31:44 linux kernel: speedstep-centrino: target=1700000kHz old=600000 new=1700000 msr=1131 Nov 15 19:31:44 linux kernel: cpufreq-core: notification 0 of frequency transition to 1700000 kHz Nov 15 19:31:44 linux kernel: userspace: saving cpu_cur_freq of cpu 0 to be 1700000 kHz Nov 15 19:31:44 linux kernel: cpufreq-core: scaling loops_per_jiffy to 6784288 for frequency 1700000 kHz Nov 15 19:31:44 linux kernel: cpufreq-core: notification 1 of frequency transition to 1700000 kHz Nov 15 19:31:44 linux kernel: userspace: saving cpu_cur_freq of cpu 0 to be 1700000 kHz Nov 15 19:31:44 linux kernel: cpufreq-core: governor: change or update limits Nov 15 19:31:44 linux kernel: cpufreq-core: __cpufreq_governor for CPU 0, event 3 Nov 15 19:31:44 linux kernel: performance: setting to 1700000 kHz because of event 3 Nov 15 19:31:44 linux kernel: cpufreq-core: target for CPU 0: 1700000 kHz, relation 1 Nov 15 19:31:44 linux kernel: freq-table: request for target 1700000 kHz (relation: 1) for cpu0 Nov 15 19:31:44 linux kernel: freq-table: target is 1 (1700000 kHz, 4401) Sorry for the confusing information, tell me if you need anything else. I hope you can find something with that, hopping from ACPI processor and frequ limiting code to cpufreq_core/cpufreq_table and speedstep-centrino driver code is a nightmare ...
Ah yes, I tried that with SL 10.0 and more recent kernels (2.6.14-rcX), so this problem should still be valid for mainline kernels.
Any news on this?
I cannot find a code bug in kernel. Let's wait for Venkatesh to return from holiday... I think I found the place where things go wrong, just some lines: freq_table.c:cpufreq_frequency_table_target() at the end: Nov 15 19:19:05 linux kernel: freq-table: target is 7 (600000 kHz, 1552) speedstep-centrino.c:centrino_target(): Nov 15 19:19:05 linux kernel: speedstep-centrino: no change needed - msr was and needs to be 610 For me it should have stored the 1552 value and compare with current msr value. This would be some kind of compiler/optimization bug?!? Venki: Could you recheck if I did follow up a pointer wrong: msr = centrino_model[cpu]->op_points[newstate].index; -> this should be 1152 as told in cpufreq_frequency_table_target()? If I missread something I expect it's something like msr returns that 600 000 MHz are already set because of working on battery, but that is wrong and it needs to be forced to be overwritten..., that would make more sense. The same for going up after ac_adapter is plugged in again. Stefan, I think I could fix this, can I have a DELL again? Venkatesh is returning on the 17th of Jan from vacation, quite late for us?
Yes, we have now one available.
I got it. I sent patches mainline and wait for answer/review now. The patches should be save to be included in 10.0, please stay tuned.
No reply yet, also included lmkl now, not only the cpufreq list... I will commit the first patch that makes at least the ondemand governor work into our stable (Beta3) kernel. If I don't hear complains, I will also add it to 10.0. The other one (make also userspace governor work) I have to wait for comments. Just for the records, I will also attach them here...
Created attachment 64821 [details] Make cpufreq-core aware of cpufreq changes done behind the back of kernel by BIOS
Created attachment 64823 [details] Delete an unnecessary struct - make userspace governor use of global freq policy, so it cannot forget to copy any policy struct members
The problem is not unique to the userspace governor. I am using ondemand governor, and the behaviour is the same on two Centrino laptops. An annoying workaround is to do # cpufreq-set -u 1.5G (put the top speed of the chip in insetead of 1.5) after AC is re-connected. It is definitely not that the speed is being reported incorrectly: the machine remains notably slow after coming back an AC-off/AC-on cycle. I have this on a Dell Inspiron 8600 (1.5GHz Centrino) and a Dell Latitude X1, which is a re-badged Samsung, 1.1GHz Centrino. See the following. Note the "current policy" line. AC on - original state: juno:~ # cpufreq-info cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: centrino CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.10 GHz available frequency steps: 1.10 GHz, 800 MHz, 600 MHz available cpufreq governors: ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). Now on batteries juno:~ # cpufreq-info cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: centrino CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.10 GHz available frequency steps: 1.10 GHz, 800 MHz, 600 MHz available cpufreq governors: ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). AC back, but still slow juno:~ # cpufreq-info cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: centrino CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.10 GHz available frequency steps: 1.10 GHz, 800 MHz, 600 MHz available cpufreq governors: ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 600 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.10 GHz (asserted by call to hardware). Get my speed back! juno:~ # cpufreq-set -u 1.1G juno:~ # cpufreq-info cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: centrino CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.10 GHz available frequency steps: 1.10 GHz, 800 MHz, 600 MHz available cpufreq governors: ondemand, userspace, powersave, performance current policy: frequency should be within 600 MHz and 1.10 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). juno:~ #
"The problem is not unique to the userspace governor. I am using ondemand governor, and the behaviour is the same on two Centrino laptops." -> I know. The first patch is a general fix in cpufreq-core that is sufficient to make the ondemand governor work. The second patch also fixes the userspace govornor. I will only check in the first patch in 10.0 which is more safe and fixes our default governor in 10.0. I have now checked in the first patch for 10.0 branch and Stable. The userspace governor patch will follow in stable as soon as I get the final OK from Venkatesh. You may want to use this kernel until the next YOU update kernel for 10.0 is available (what might take some time...): ftp.suse.com/pub/people/trenn/10_0-DELL_cpufreq_fixe d_kernel/kernel-default-2.6.13-4.i586.rpm Sorry, I don't get the point of your cpufreq output. Notice that something weird is happening on a DELL600 (probably all the same on all DELLs?): If unplugging ac adapter, the BIOS limits cpufreq to the lowest freq. After 10secs of staying at maxfreq==lowest freq, BIOS reallows all freqs again, whether you put in the ac adapter or not. You can check that by stopping powersave and acpi daemon services and do a cat /proc/acpi/event If a processor event happens, the last value should be the amount of allowed frequencies IIRC (in my case it was 1 or 6). With above patches, the kernel will handle this right. Be aware that you still have to use the ondemand governor and that for some seconds, when unplugging ac adapter you still only have the lowest freq, what is intended by BIOS (not sure what sense that make, though). Plugging the ac adapter in must provide you all freqs immediately again.
Thomas The point of the cpufreq-info output is that after ac has been restored, it continues to report "current policy: frequency should be within 600 MHz and 600 MHz" and it is apparent that this is accurate because the machine is slow, and remains slow. This never changes without cpufreq-set. I will try the revised kernel, thanks.
This bug is back in 10.1 Beta3. If I remove the AC adapter the scaling_max_freq is set to 600000 and never again higher.
@thomas: timo checked this with kernel-default-2.6.16_rc3_git3-2.rpm and a DELL D600 and the problem is also in this kernel present. But after cpufreq-set -u 1.7G it work (I think this is the same as echo 1700000 > scaling_max_freq)
This was with userspace governor? I only checked in the ondemand fix and submitted both patches for mainline... I hopped both come in automagically, will check... If this was the userspace governor, only the max_freq value should be wrong until the next freq is set, but the frequency itself should already have been set correctly IIRC.
I just checked Dave Jones cpufreq git tree. They are already in and hopefully pop up mainline soon, this would avoid work and risk. I contacted Dave and asked when they are going to be pushed. If it takes too long I will add them into our CVS. I now wait for an answer...
You should put this now in our CVS or provide a kernel with this patch. We need this now to test this during the BETA phase and not in 1,2 or more weeks.
They are already mainline and found their way into our kernel... Please try the latest kotd.
This problem is still present with the beta8/STABLE kernel and kotd (2.6.16_rc6_git9).
Hmm, the last processor event (the one 10 seconds after plugging AC in again) does not set up max freq again. Waiting for machine to test. Reducing severity as the machine now always works on max freq when working on AC power. BTW, this machine never worked for SL 9.3, 10.0, ..., why should this be a blocker now?
No this was a mistake because the machine also on AC does not set the correct max freq. Btw. The statement "this machine never worked for SL 9.3, 10.0, ...," is no reason for set the severity and the bug was first filed against 10.0.
Of course it worked with 9.3 and before, so this is a regression. And it has a large severity because running notebook at 600MHz all the times makes the notebook more or less useless nowadays, so it's quite severe. I'm a little bit confused from last two comments, so what's the current status now? Thanks M.
Status: I'll hand over a D600 to Thomas today. So he's actually able to debug the bug. Wishful thinking: Issue is fixed tonight :-)
Moving to Beta 8.
The root cause is fixed. This only happens after suspend/resume. I will try again tomorrow.
*** Bug 156266 has been marked as a duplicate of this bug. ***
JFYI: an other effected machine: DELL Latitude C640
comment #52 is wrong. This happens sometimes, so it seems to be some kind of nasty race condition. I wonder whether it could have something to do with the latest mutex<->semaphore changes. Possibly it's much older but we see it since some debug options were disabled. This bug is totally unrelated to the previous, initially described, DELL specific problem. This bug should effect all machines that do cpufreq limitations through BIOS (_PPC function) at runtime. Whether the BIOS sends cpufreq limitation events can be found by: grep processor /var/log/acpid -> Search for a processor event with No. 0x80 and a not 0 at the end. 0 Means all frequs are allowed again. E.g. 1 means only two freqs the highest(0) and the second highest(1) are allowed now. Coolo's modern Thinkpad also has this problem when running on default BIOS setting "Battery Optimised" -> CC'ing
This seem to be some very nasty locking problem. I can only reproduce the problem with the ondemand governor. I already spent too much time on this one. The code is clustered with locks... and is rather complicated. I sent Venkatesh some debug output and I hope he'll find it.
It's a race condition with powersaved sysfs writes and the ondemand governor. Powersave daemon always rewrites its cpu config to /sys/... after a policy change occurs (e.g. when un-/replugging AC) and here I expect the race to happen. When stopping the powersaved everything goes right. Holger, can you verify that the powersave daemon does not write the max_freq itself. I searched the code and increased debug, I only saw it writing ondemand config options in /sys/.../cpufreq/ondemand/* I give the machine back to Timo as I am not here tomorrow. Maybe Venkatesh can reproduce this now...
Venkatesh: Could it be that ondemand sysfs write functions like (can't check now, have to leave): static ssize_t store_sampling_down_factor(struct cpufreq_policy *unused, const char *buf, size_t count) are somehow connected to the main cpufreq.c store functions where a get_policy set_policy happens? Then I think this is it. In this case the mutex_lock(&dbs_mutex); needs to go all around the get_policy set_policy calls. Just a last idea...
Thomas, powersaved does not touch scaling_max_freq. It only sets ondemand specific configs below /sys/.../cpufreq/ondemand/ .
ondemand sysfs write functions does not directly call get/set policy. But, as ondemand has parent of policy->kobj, I think (havent checked it yet) any write will go through show/store routnines in cpufreq and which will in turn call cpufreq_cpu_get() and cpufreq_cpu_put().
Finally got it... (Thanks to Holger for tracking down sysfs writes in powersave daemon). The problem is reproducable by: - Unplugging AC -> max freq gets limited - echo ${governor} >/sys/.../cpufreq/scaling_governor (policy->user_data.max gets overridden with policy->max and will never come up again.) Powersave daemon rewrites the governor after a scheme switch (not nice, but kernel should be able to handle this, if you switch governor from ondemand->userspace max_freq also gets stuck at low freq if it was limited at that moment. Fix will follow. Venkatesh: I simply removed the cpufreq_set_policy call to __cpufreq_set_policy and duplicated it's functionality but did not override user_data.max. This should be OK? However I am not 100% sure about the lock all get_policy...set_policy.
Created attachment 76338 [details] See comment above Not yet commited. I will wait for some comments from Venkatesh and/or the cpufreq list (We are at Beta9). Test builds: stravinsky-trenn-153
Created attachment 76340 [details] Fix max_freq override when changing governor This one should build ...
Test builds: stravinsky-trenn-154
I commited the patch now. Would be nice if one of the laptop guys could install a kotd tomorrow and have a short look whether the cpufreq still works as expected (I tested this, but verification would be appreciated). watch -n1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_* and give some load and un-,replug AC should be enough for a quick test. Be sure ondemand stays the scaling governor.
Great work root causing this one. Patch looks fine. A minor comment on the patch. It can be simplified by taking the mutex lock only around 3 lines starting at __cpufreq_set_policy. Otherwise patch looks perfect to me. Is this not a issue with scaling_max_freq and scaling_min_freq setting from userspace. Those use set_policy as well and clip max and minimum freq. Say, scaling_max and scaling_min is 1600000 and 600000 resp. And we switch to battery. And user does echo 600000 > scaling_min_freq or echo 800000 > scaling_min_freq Then does scaling_max_freq does it get stuck at 600000 again? On different note: You mentioned some ondemand tunables under /sys/.../cpufreq/ondemand/* is being set in initialization. Just out of curiousity, what parameters are you changing and to what values? Thanks.
(In reply to comment #66) > On different note: > You mentioned some ondemand tunables under > /sys/.../cpufreq/ondemand/* > is being set in initialization. Just out of curiousity, what parameters are you > changing and to what values? > Thanks. I'll answer this one :-) root@strolchi:/sys/devices/system/cpu/cpu0/cpufreq/ondemand> grep . * ignore_nice_load:0 sampling_down_factor:1 sampling_rate:333000 sampling_rate_max:40000000 sampling_rate_min:40000 up_threshold:80 ignore_nice_load can be set by the user, sampling_rate also. I basically took the same values we used for the userspace implementation: 3 samples per second. The defaults of ondemand are way too "triggerhappy", it switches to full speed all the time although there is not enough to do.
> Say, scaling_max and scaling_min is 1600000 and 600000 resp. > And we switch to battery. > And user does echo 600000 > scaling_min_freq or echo 800000 > > scaling_min_freq > Then does scaling_max_freq does it get stuck at 600000 again? Yes you are right. I can do another patch ..., not sure whether I should add this one also to our CVS as this is a rather obscure scenario and I fear another bug source... you never know ... I also need to split up the #define store_ function macro into real functions e.g. store_max_freq and store_min_freq or do you know a nicer solution for that? We should also test whether the value is already set and not invoke set_policy in this case, but just return. > It can be simplified by taking the mutex lock only around 3 lines > starting at __cpufreq_set_policy. Are you sure about that? cpufreq_get_policy returns a copy of the current policy, not a pointer to the actual running policy. I feared that old values could override a already changed (between get and set) policy?
Patch is not included in Beta10/RC1 due to a lock and a refcount bug. I sent a fixed version to cpufreq list and reenabled the fix, should be in RC2. Watch out for: - patches.fixes/cpufreq_sysfs_max_override.patch: Max freq stucks at low freq if reduced by _PPC and sysfs gov access (119836). Reenabled after fixing lock and refcount issues. in kernel's rpm changelog.