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:800000
Notice that scaling_mx_freq dropped 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
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.
Auke
On Thu, 05 Jun 2008, Kok, Auke wrote:
> This renders my Dothan to utterly poor speeds. (standard T43)
Which ThinkPad T43 model and BIOS revision?
I have a T43 2687DDU with the latest BIOS, and I have never seen
anything like that happening. Is it overheating or something like that?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Thu, 05 Jun 2008, Kok, Auke wrote:
>> This renders my Dothan to utterly poor speeds. (standard T43)
>
> Which ThinkPad T43 model and BIOS revision?
>
> I have a T43 2687DDU with the latest BIOS, and I have never seen
> anything like that happening. Is it overheating or something like that?
>
T43 2668NU3 Version: 1YET59WW (1.24 )
hardly overheating:
Thermal zone 1 : ok, 49 C
it goes maybe up to 56C during work, but that's it.
Auke
On Fri, 06 Jun 2008 09:34:28 -0700, "Kok, Auke" <[email protected]> said:
> Henrique de Moraes Holschuh wrote:
> > On Thu, 05 Jun 2008, Kok, Auke wrote:
> >> This renders my Dothan to utterly poor speeds. (standard T43)
> >
> > Which ThinkPad T43 model and BIOS revision?
> >
> > I have a T43 2687DDU with the latest BIOS, and I have never seen
> > anything like that happening. Is it overheating or something like that?
>
> T43 2668NU3 Version: 1YET59WW (1.24 )
Older version of the planar card, but should be close enough to the
2687 I have...
Your BIOS is horribly old, and your EC firmware is very old too. You
really should upgrade to BIOS 1.29 (1YET65WW) and EC 1.06. Lenovo has
CDs you can use to upgrade even without Windows. thinkwiki.org has the
links to the support pages with the downloads.
After you upgrade, go into the BIOS configuration screen, and set everything
related to Speedstep and performance management to highest performance. You
can let the BIOS do BUS power management, and you should let it do screen
brightness power management, but don't let it mess with the processor speed
or the disks. It can have bad interactions with Linux power management.
> hardly overheating:
>
> Thermal zone 1 : ok, 49 C
It is probably a bad interaction from SMBIOS power management with the native
Linux power management.
BTW: install thinkpad-acpi and lm-sensors 3.0, and you will be able to see the
11 thermal zones the EC controls in a T43.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Thu, 5 Jun 2008, Kok, Auke wrote:
>
> 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:800000
>
>
>
> Notice that scaling_mx_freq dropped 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
>
>
> 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.
could be two causes:
1. thermal
2. user space
for #1....
watch grep . /proc/acpi/thermal_zone/THM*/*
and see if anythign is climbing
you can build w/o CONFIG_ACPI_THERMAL
and see if they symptom goes away -- for that
is the module which would force cpufreq to Pn.
for #2...
see if it happens in single user mode without
hal or distro daemons running.
cheers,
-Len
Hi!
> 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:800000
>
>
>
> Notice that scaling_mx_freq dropped 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
>
>
> 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, 7 Jun 2008 23:39:18 +0200
Pavel Machek <[email protected]> wrote:
> > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > 800000
> > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > 800000
> >
> >
> > 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
>
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...
--
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
On 2008.06.05 15:30:56 -0700, Kok, Auke wrote:
>
> 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:800000
>
I also saw that on my T43, didn't have time to investigate any further
and forgot about it shortly after :-(
>
> Notice that scaling_mx_freq dropped 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
Try with "echo -n", seems that sysfs (or at least that file) doesn't
like newlines.
Bj?rn
On Sat 07. Jun - 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <[email protected]> wrote:
>
> > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > 800000
> > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > 800000
> > >
> > >
> > > 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
> >
>
>
> 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
Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <[email protected]> wrote:
>
>>> # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
>>> 800000
>>> # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
>>> 800000
>>>
>>>
>>> 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
>>
>
>
> 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
On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <[email protected]> wrote:
>
> > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > 800000
> > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > 800000
> > >
> > >
> > > 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
> 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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 16 Jun 2008 12:42:00 +0200
Pavel Machek <[email protected]> wrote:
> On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> > On Sat, 7 Jun 2008 23:39:18 +0200
> > Pavel Machek <[email protected]> wrote:
> >
> > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > 800000
> > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > 800000
> > > >
> > > >
> > > > 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
>
> > 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!
> > > 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.
Not a good idea, but what's the alternative? It seems like BIOS always
leaves him at 800MHz unless he ignores it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > 800000
> > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > 800000
> > > >
> > > >
> > > > 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
>
> > 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
On 2008.06.16 07:43:37 -0700, Arjan van de Ven wrote:
> On Mon, 16 Jun 2008 12:42:00 +0200
> Pavel Machek <[email protected]> wrote:
>
> > On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> > > On Sat, 7 Jun 2008 23:39:18 +0200
> > > Pavel Machek <[email protected]> wrote:
> > >
> > > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > > 800000
> > > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > > 800000
> > > > >
> > > > >
> > > > > 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
> >
> > > 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.
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
On 2008.07.05 21:49:08 +0200, Bj?rn Steinbrink wrote:
> On 2008.06.16 07:43:37 -0700, Arjan van de Ven wrote:
> > On Mon, 16 Jun 2008 12:42:00 +0200
> > Pavel Machek <[email protected]> wrote:
> >
> > > On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> > > > On Sat, 7 Jun 2008 23:39:18 +0200
> > > > Pavel Machek <[email protected]> wrote:
> > > >
> > > > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > > > 800000
> > > > > > # echo 1866000 > scaling_max_freq ; cat scaling_max_freq
> > > > > > 800000
> > > > > >
> > > > > >
> > > > > > 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
> > >
> > > > 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.
>
> 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:
>
[snip]
>
>
> 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