bug? acpi p-state + ondemand keeps dropping max freq

DISCUSSION Beglin, Brad R 3 participants 3 messages Jun 10, 2008 – Jul 8, 2008

Share & tools

Beglin, Brad R

author

2008-06-10 22:40 UTC #0 lore raw

Quoted 4 lines

I am also unable to change my max scaling frequency on my Thinkpad T61. Interestingly enough, I can change the frequency as long as the new value is less than 1.2 GHz. If I try to set the new max frequency higher than that, the max scaling frequency file reverts to 1.2GHz. Here is in example:

Well, I did a lot more research, and it seems, at least in my case and probably others, that this is a long-time know bug, as detailed here:

http://bugzilla.kernel.org/show_bug.cgi?id=7060
http://lkml.org/lkml/2007/1/16/120
http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling
http://forums.lenovo.com/lnv/board/message?board.id=T_Series_Thinkpads&thread.id=7420

However, I can report, as outlined in the Thinkwiki.org article, that adding "processor.ignore_ppc=1" to the kernel boot parameters fixed the problem for me (with kernel 2.6.25-r4).

I hope this helps the others who are having the same problem. mp.

--
Brad R. Beglin
Computational Media Undergraduate
Georgia Institute of Technology

Thomas Renninger

2008-06-13 14:21 UTC #1 lore raw

Quoted 5 lines · Brad R

Quoted 4 lines
I am also unable to change my max scaling frequency on my Thinkpad T61. Interestingly enough, I can change the frequency as long as the new value is less than 1.2 GHz. If I try to set the new max frequency higher than that, the max scaling frequency file reverts to 1.2GHz. Here is in example:

Quoted 7 lines

Well, I did a lot more research, and it seems, at least in my case and probably others, that this is a long-time know bug, as detailed here:
http://bugzilla.kernel.org/show_bug.cgi?id=7060
http://lkml.org/lkml/2007/1/16/120
http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling
http://forums.lenovo.com/lnv/board/message?board.id=T_Series_Thinkpads&thread.id=7420

Be careful, these reports have different causes.
E.g.:
---
If the battery pack is removed and the laptop is powered by AC only, the CPU downclocks to the lowest multiplier and remains locked in low speed
---
Might be a BIOS bug (or even intended?).

Quoted 7 lines

However, I can report, as outlined in the Thinkwiki.org article, that adding
"processor.ignore_ppc=1" to the kernel boot parameters fixed the problem for me
(with kernel 2.6.25-r4).
I hope this helps the others who are having the same problem. mp.

Arkadiusz has provided some interesting debug results.
He and some others reported cpufreq limitation to the lowest freq on some boots. I am pretty sure this is not a BIOS issue as _PPC is always 0 there.

Beglin: If you could compile CPU_FREQ_DEBUG in and boot with cpufreq.debug=7. If you run into this issue and grep for:
dmesg |grep -i ppc
you probably see the same issue than Arkadiusz which probably is not a BIOS but a kernel error.

Arkadiusz: If you run into this again can you check whether you have:
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias set (if yes, this should only be set when working on battery?).

Another idea:
Maybe increasing /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate helps?

Strange seem to be the duplicate messages and duplicate tries to set the same freq over and over again.

Also there seem some frequencies tried to be set which should not exist:
152342 kHz, 57142 kHz, 0 kHz

comment lines starting with ####

Here is again an interesting part of the debug messages:
May 26 17:28:55 tarm kernel: [ 1596.625686] freq-table: target is 0 (2000000 kHz, 0)

May 26 17:29:04 tarm kernel: [ 1605.626418] __ratelimit: 10 messages suppressed
May 26 17:29:04 tarm kernel: [ 1605.626630] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:29:04 tarm kernel: [ 1605.626772] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)
May 26 17:29:24 tarm kernel: [ 1625.625002] __ratelimit: 40 messages suppressed
May 26 17:29:24 tarm kernel: [ 1625.625218] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:29:24 tarm kernel: [ 1625.625363] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)
May 26 17:29:24 tarm kernel: [ 1625.625501] freq-table: request for target 2000000 kHz (relation: 1) for cpu 0
May 26 17:29:24 tarm kernel: [ 1625.625643] freq-table: target is 0 (2000000 kHz, 0)
May 26 17:29:39 tarm kernel: [ 1641.125020] __ratelimit: 31 messages suppressed
May 26 17:29:39 tarm kernel: [ 1641.125248] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:29:39 tarm kernel: [ 1641.125387] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)

May 26 17:29:39 tarm kernel: [ 1641.125519] freq-table: request for target 2000000 kHz (relation: 1) for cpu 0
May 26 17:29:43 tarm kernel: [ 1644.624994] __ratelimit: 16 messages suppressed

#### This means the message:
#### freq-table: request for target 2000000 kHz (relation: 1) for cpu 0 #### got printed/processed 16 times? This is not possible.
#### The message should come from:
#### drivers/cpufreq/cpufreq.c:__cpufreq_driver_target()
#### Which should invoke: acpi-cpufreq:acpi_cpufreq_target() which should print:
#### dprintk("acpi_cpufreq_target %d (%d)\n", target_freq, policy->cpu);

#### Hmm, could it be that the cpufreq specific ratelimit implementation #### swallows some debug messages?

May 26 17:29:43 tarm kernel: [ 1644.625160] cpufreq-core: target for CPU 0: 152342 kHz, relation 0
May 26 17:30:05 tarm kernel: [ 1666.625410] __ratelimit: 6 messages suppressed
May 26 17:30:05 tarm kernel: [ 1666.625629] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:30:05 tarm kernel: [ 1666.625774] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)
May 26 17:30:05 tarm kernel: [ 1666.625912] freq-table: request for target 2000000 kHz (relation: 1) for cpu 0
May 26 17:30:05 tarm kernel: [ 1666.626054] freq-table: target is 0 (2000000 kHz, 0)
May 26 17:30:12 tarm kernel: [ 1674.125189] __ratelimit: 17 messages suppressed
May 26 17:30:12 tarm kernel: [ 1674.125425] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:30:13 tarm kernel: [ 1674.624988] __ratelimit: 6 messages suppressed
May 26 17:30:13 tarm kernel: [ 1674.625130] cpufreq-core: target for CPU 0: 0 kHz, relation 0
May 26 17:30:18 tarm kernel: [ 1680.124993] __ratelimit: 13 messages suppressed
May 26 17:30:18 tarm kernel: [ 1680.125137] cpufreq-core: target for CPU 0: 57142 kHz, relation 0
May 26 17:30:23 tarm kernel: [ 1684.625011] __ratelimit: 41 messages suppressed
May 26 17:30:23 tarm kernel: [ 1684.625238] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:30:25 tarm kernel: [ 1687.103612] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 kHz
May 26 17:30:25 tarm kernel: [ 1687.103851] acpi-cpufreq: acpi_cpufreq_verify
May 26 17:30:25 tarm kernel: [ 1687.103983] freq-table: request for verification of policy (800000 - 2000000 kHz) for cpu 0
May 26 17:30:25 tarm kernel: [ 1687.104121] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 0
May 26 17:30:25 tarm kernel: [ 1687.104257] acpi-cpufreq: acpi_cpufreq_verify
May 26 17:30:25 tarm kernel: [ 1687.104385] freq-table: request for verification of policy (800000 - 800000 kHz) for cpu 0
May 26 17:30:25 tarm kernel: [ 1687.104521] freq-table: verification lead to (800000 - 800000 kHz) for cpu 0
May 26 17:30:25 tarm kernel: [ 1687.104656] cpufreq-core: new min and max freqs are 800000 - 800000 kHz
May 26 17:30:25 tarm kernel: [ 1687.104788] cpufreq-core: governor: change or update limits
May 26 17:30:25 tarm kernel: [ 1687.105041] cpufreq-core: __cpufreq_governor for CPU 0, event 3
May 26 17:30:33 tarm kernel: [ 1695.412124] __ratelimit: 25 messages suppressed

#### __cpufreq_governor for CPU 0, event 3 happended 25 times?!?

May 26 17:30:33 tarm kernel: [ 1695.412329] cpufreq-core: CPU 0: _PPC is 0 - frequency not limited
May 26 17:30:33 tarm kernel: [ 1695.412490] cpufreq-core: updating policy for CPU 0
May 26 17:30:33 tarm kernel: [ 1695.412623] cpufreq-core: setting new policy for CPU 0: 800000 - 2000000 kHz
May 26 17:30:33 tarm kernel: [ 1695.412757] acpi-cpufreq: acpi_cpufreq_verify
May 26 17:30:33 tarm kernel: [ 1695.413087] freq-table: request for verification of policy (800000 - 2000000 kHz) for cpu 0
May 26 17:30:33 tarm kernel: [ 1695.413265] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 0
May 26 17:30:33 tarm kernel: [ 1695.413402] acpi-cpufreq: acpi_cpufreq_verify
May 26 17:30:33 tarm kernel: [ 1695.413529] freq-table: request for verification of policy (800000 - 2000000 kHz) for cpu 0
May 26 17:30:33 tarm kernel: [ 1695.413664] freq-table: verification lead to (800000 - 2000000 kHz) for cpu 0
May 26 17:30:33 tarm kernel: [ 1695.413798] cpufreq-core: new min and max freqs are 800000 - 2000000 kHz
May 26 17:30:33 tarm kernel: [ 1695.413929] cpufreq-core: governor: change or update limits
May 26 17:30:33 tarm kernel: [ 1695.414056] cpufreq-core: __cpufreq_governor for CPU 0, event 3
May 26 17:30:51 tarm kernel: [ 1712.625338] __ratelimit: 3 messages suppressed
May 26 17:30:51 tarm kernel: [ 1712.625566] cpufreq-core: target for CPU 0: 2000000 kHz, relation 1
May 26 17:30:51 tarm kernel: [ 1712.625711] acpi-cpufreq: acpi_cpufreq_target 2000000 (0)
May 26 17:30:51 tarm kernel: [ 1712.625863] freq-table: request for target 2000000 kHz (relation: 1) for cpu 0

To be honest, I do not see it...

Thomas

_______________________________________________
Cpufreq mailing list
[email protected]
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Arkadiusz Miskiewicz

2008-07-08 10:57 UTC #2 lore raw

Quoted 43 lines · Thomas Renninger

Quoted 6 lines · Brad R
Quoted 5 lines
I am also unable to change my max scaling frequency on my Thinkpad T61. Interestingly enough, I can change the frequency as long as the new value is less than 1.2 GHz. If I try to set the new max frequency higher than that, the max scaling frequency file reverts to 1.2GHz. Here is in example:
Quoted 8 lines
Well, I did a lot more research, and it seems, at least in my case and probably others, that this is a long-time know bug, as detailed here:
http://bugzilla.kernel.org/show_bug.cgi?id=7060
http://lkml.org/lkml/2007/1/16/120
http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling
http://forums.lenovo.com/lnv/board/message?board.id=T_Series_Thinkpads&th
read.id=7420
Be careful, these reports have different causes.
E.g.:
---
If the battery pack is removed and the laptop is powered by AC only, the CPU downclocks to the lowest multiplier and remains locked in low speed
---
Might be a BIOS bug (or even intended?).
Quoted 7 lines
However, I can report, as outlined in the Thinkwiki.org article, that adding
"processor.ignore_ppc=1" to the kernel boot parameters fixed the problem for me
(with kernel 2.6.25-r4).
I hope this helps the others who are having the same problem. mp.
Arkadiusz has provided some interesting debug results.
He and some others reported cpufreq limitation to the lowest freq on some boots. I am pretty sure this is not a BIOS issue as _PPC is always 0 there.
Beglin: If you could compile CPU_FREQ_DEBUG in and boot with cpufreq.debug=7. If you run into this issue and grep for:
dmesg |grep -i ppc
you probably see the same issue than Arkadiusz which probably is not a BIOS but a kernel error.

Quoted 3 lines

Arkadiusz: If you run into this again can you check whether you have:
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias set (if yes, this should only be set when working on battery?).

Was zero there afail. (I did the test some time ago after seeing this mail but forgot to reply 8-)

Quoted 4 lines

Another idea:
Maybe increasing /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate helps?

Didn't help. I was trying to various values there.

Quoted 8 lines

Strange seem to be the duplicate messages and duplicate tries to set the same freq over and over again.
Also there seem some frequencies tried to be set which should not exist:
152342 kHz, 57142 kHz, 0 kHz
Thomas

Signature · 7 lines

Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

_______________________________________________
Cpufreq mailing list
[email protected]
http://lists.linux.org.uk/mailman/listinfo/cpufreq