bug? acpi p-state + ondemand keeps dropping max freq
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi!
Quoted 30 lines
I've consistently experienced the following bizarre problem since 2.6.20, all the way up to 2.6.25.3 (regressed yesterday and each of these kernels exposes this behaviour):
/sys/devices/system/cpu/cpu0/cpufreq# grep . * affected_cpus:0
cpuinfo_cur_freq:800000
cpuinfo_max_freq:1866000
cpuinfo_min_freq:800000 scaling_available_frequencies:1866000 1600000 1333000 1066000 800000 scaling_available_governors:ondemand performance scaling_cur_freq:800000
scaling_driver:acpi-cpufreq
scaling_governor:ondemand
scaling_max_freq:800000
scaling_min_freq:800000Notice that
scaling_mx_freqdropped down to the lowest possible value and as such my CPU is only working at 800MHz. At boot time this field properly displays 1866MHz and everything works OK. After a certain period (?) this value drops down and I cannot manually elevate it back to the normal level:# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000
Quoted 4 lines
This renders my Dothan to utterly poor speeds. (standard T43)
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
https://bugzilla.novell.com/show_bug.cgi?id=396311
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 8 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
Quoted 9 lines
Quoted 2 lines
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
https://bugzilla.novell.com/show_bug.cgi?id=396311
Pavel
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
Signature · 3 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org
Quoted 22 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
Quoted 9 lines
Quoted 2 lines
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
https://bugzilla.novell.com/show_bug.cgi?id=396311
Pavel
Quoted 5 lines
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
I'm not aware of any 'brand' of kpowersave or gnome-power-manager which could interfere here. Nor I'm aware of any backends in recent distros which tweak the 'max freq' knobs. So I don't think this can be related. Or please be a little bit more detailed about what you're referring to...
Regards,
Holger
Quoted 21 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
Quoted 8 lines
Quoted 2 lines
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
https://bugzilla.novell.com/show_bug.cgi?id=396311
Pavel
Quoted 5 lines
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
I neither run gnome nor kde. there's nothing running on this box that is managing power settings.
Auke
Quoted 16 lines · Arjan van de Ven
Quoted 13 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 10 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
Quoted 7 lines
Quoted 1 line
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 20 lines · On Mon, 16 Jun 2008 12:42:00 +0200 Pavel Machek <[email protected]> wrote:
Quoted 18 lines · Arjan van de Ven
Quoted 15 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 10 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
Quoted 8 lines
Quoted 5 lines
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
well as long as the user doesn't use this for production use... the BIOS often reduces frequencies available to deal with thermal situations, so it's not a good idea to ignore that.
Hi!
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
Quoted 6 lines
Quoted 2 lines
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
well as long as the user doesn't use this for production use... the BIOS often reduces frequencies available to deal with thermal situations, so it's not a good idea to ignore that.
Not a good idea, but what's the alternative? It seems like BIOS always leaves him at 800MHz unless he ignores it.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 29 lines · Arjan van de Ven
Quoted 26 lines · On Mon, 16 Jun 2008 12:42:00 +0200 Pavel Machek <[email protected]> wrote:
Quoted 24 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
Quoted 7 lines
Quoted 2 lines
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
Quoted 6 lines
Quoted 2 lines
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
well as long as the user doesn't use this for production use... the BIOS often reduces frequencies available to deal with thermal situations, so it's not a good idea to ignore that.
Yep, seems to be a thermal thing. I managed to find some time to play around with it a bit, and running a cpu hog for a short period of time, while watching temperature and scaling_max_freq showed this:
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 49 C
cpufreq# cat scaling_max_freq
1866000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 51 C
cpufreq# cat scaling_max_freq
1866000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 52 C
cpufreq# cat scaling_max_freq
1866000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 53 C
cpufreq# cat scaling_max_freq
1866000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 54 C
cpufreq# cat scaling_max_freq
800000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 53 C
cpufreq# cat scaling_max_freq
800000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 51 C
cpufreq# cat scaling_max_freq
800000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 51 C
cpufreq# cat scaling_max_freq
800000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 50 C
cpufreq# cat scaling_max_freq
800000
cpufreq# cat /proc/acpi/thermal_zone/THM0/temperature
temperature: 49 C
cpufreq# cat scaling_max_freq
1866000
So upon reaching 54°C some throttling kicks in and only when going back to less then 50°C, that limit is lifted again. Too bad that with Linux, this T43 already runs at about 47°C when idle, so as soon as there's any load on the cpu, it will scale up for a few seconds and then get throttled :-(
There's no userspace powersave foo involved here, just the plain ondemand scaling governor, same happens with the performance governor.
Björn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 41 lines · Björn Steinbrink
Quoted 29 lines · Arjan van de Ven
Quoted 26 lines · On Mon, 16 Jun 2008 12:42:00 +0200 Pavel Machek <[email protected]> wrote:
Quoted 24 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 7 Jun 2008 23:39:18 +0200 Pavel Machek <[email protected]> wrote:
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000This renders my Dothan to utterly poor speeds. (standard T43)
Quoted 7 lines
Quoted 2 lines
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
Quoted 6 lines
Quoted 2 lines
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
well as long as the user doesn't use this for production use... the BIOS often reduces frequencies available to deal with thermal situations, so it's not a good idea to ignore that.
Yep, seems to be a thermal thing. I managed to find some time to play around with it a bit, and running a cpu hog for a short period of time, while watching temperature and
scaling_max_freqshowed this:
[snip]
Quoted 7 lines
So upon reaching 54°C some throttling kicks in and only when going back to less then 50°C, that limit is lifted again. Too bad that with Linux, this T43 already runs at about 47°C when idle, so as soon as there's any load on the cpu, it will scale up for a few seconds and then get throttled :-(
OK, a stop at thinkwiki[1] later, I know what's happening now. The BIOS has a few settings regarding CPU speed on AC/battery. One is about balancing power and noise. The above throttling does no longer kick in if that option is set to "Maximum Power".
Björn
[1] http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling#Troubleshooting
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Len Brown
reviewerQuoted 17 lines
Quoted 16 lines
Quoted 16 lines
Quoted 8 lines
# echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000 # echo 1866000 > scaling_max_freq ; cat scaling_max_freq 800000Quoted 4 lines
This renders my Dothan to utterly poor speeds. (standard T43)
performance cpufreq governor makes no difference - I still can't change the frequency upper/lower values.
Hmm, I have similar problem in Novell bugzilla, on very different hw:
Quoted 8 lines
Quoted 5 lines
are either of you running gnome-power-manager or kpowersaved ? sometimes these programs (and more likely, the patches added by a distro maintainer who doesn't fully realize how power works) tend to muck with kernel settings around CPU frequency that they have absolutely no business touching...
In novel bugzilla case ignore_ppc=1 helped, so it seems to be BIOS problem, not userland's...
Thanks for the pointer to the novell report, Pavel.
I poked at that one and I think it may actually be a table loading issue for which we've just send a patch to 2.6.26.
Auke,
Please open a signting in bugzilla and attach your dmesg and acpidump output.
Also, please report if processor.ignore_ppc=1 helps.
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
thanks,
-Len