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

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

[Kok, Auke]

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

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

[Henrique de Moraes Holschuh]

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

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

[Kok, Auke]

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

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

[Henrique de Moraes Holschuh]

On Fri, 06 Jun 2008 09:34:28 -0700, "Kok, Auke" <auke-jan.h.kok@intel.com> 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

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

[Len Brown]

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

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

[Björn Steinbrink]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Björn Steinbrink]

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

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

[Pavel Machek]

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

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

[Arjan van de Ven]

On Sat, 7 Jun 2008 23:39:18 +0200
Pavel Machek <pavel@suse.cz> 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 arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Arjan van de Ven]

On Sat, 7 Jun 2008 23:39:18 +0200
Pavel Machek <pavel@suse.cz> 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 arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

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

[Holger Macht]

On Sat 07. Jun - 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <pavel@suse.cz> 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

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

[Holger Macht]

On Sat 07. Jun - 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <pavel@suse.cz> 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

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

[Kok, Auke]

Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <pavel@suse.cz> 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

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

[Pavel Machek]

On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <pavel@suse.cz> 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

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

[Pavel Machek]

On Sat 2008-06-07 14:54:35, Arjan van de Ven wrote:
> On Sat, 7 Jun 2008 23:39:18 +0200
> Pavel Machek <pavel@suse.cz> 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

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

[Arjan van de Ven]

On Mon, 16 Jun 2008 12:42:00 +0200
Pavel Machek <pavel@suse.cz> 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 <pavel@suse.cz> 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.

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

[Pavel Machek]

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

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

[Björn Steinbrink]

On 2008.06.16 07:43:37 -0700, Arjan van de Ven wrote:
> On Mon, 16 Jun 2008 12:42:00 +0200
> Pavel Machek <pavel@suse.cz> 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 <pavel@suse.cz> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Björn Steinbrink]

On 2008.06.16 07:43:37 -0700, Arjan van de Ven wrote:
> On Mon, 16 Jun 2008 12:42:00 +0200
> Pavel Machek <pavel@suse.cz> 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 <pavel@suse.cz> 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

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

[Björn Steinbrink]

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 <pavel@suse.cz> 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 <pavel@suse.cz> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Björn Steinbrink]

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 <pavel@suse.cz> 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 <pavel@suse.cz> 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

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

[Len Brown]

> > > > # 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

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

[Beglin, Brad R]

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:

# echo 2001000 > scaling_max_freq ; cat scaling_max_freq
1200000

# echo 1000000 > scaling_max_freq ; cat scaling_max_freq
1000000

# echo 1600000 > scaling_max_freq ; cat scaling_max_freq
1200000

# echo 2000000 > scaling_max_freq ; cat scaling_max_freq
1200000

I have also tried to make the change while using "echo -n" with no success.  I have also attempted to use a different governor, but that has no effect.

Here is my cpufreq-info output:

cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: conservative, userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: conservative, userspace, ondemand, performance
  current policy: frequency should be within 800 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).

Hope this helps. mp.

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

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

[Beglin, Brad R]

>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 

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

[Thomas Renninger]

On Tue, 2008-06-10 at 18:40 -0400, Beglin, Brad R wrote:
> >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

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?).

> 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
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

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

[Arkadiusz Miskiewicz]

On Friday 13 June 2008, Thomas Renninger wrote:
> On Tue, 2008-06-10 at 18:40 -0400, Beglin, Brad R wrote:
> > >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&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?).
>
> > 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?).

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

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

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

>
> 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

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

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq