cpufreq stops working after a while

cpufreq stops working after a while

[Mark Lord]

One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.

I use speedstep-centrino with it, and after boot all is usually okay.
But after a few hours of operation, it stops shifting to the highest frequency
even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
and stays there until I reboot.

Sometimes rebooting doesn't even restore it.

/sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
showing the available frequencies and other info.  All of the attribs
there look fine, except for "scaling_max_freq", which is what seems
to gradually get set smaller.  For instance, right now it is set to 800000,
and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.

WHY?  And how can I fix it?

Re: cpufreq stops working after a while

[Dave Jones]

On Fri, Aug 11, 2006 at 02:25:26PM -0400, Mark Lord wrote:
 > One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
 > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
 > 
 > I use speedstep-centrino with it, and after boot all is usually okay.
 > But after a few hours of operation, it stops shifting to the highest frequency
 > even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
 > and stays there until I reboot.
 > 
 > Sometimes rebooting doesn't even restore it.
 > 
 > /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
 > showing the available frequencies and other info.  All of the attribs
 > there look fine, except for "scaling_max_freq", which is what seems
 > to gradually get set smaller.  For instance, right now it is set to 800000,
 > and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.
 > 
 > WHY?  And how can I fix it?

boot with cpufreq.debug=7, and capture dmesg output after it fails
to transition.  This might be another manifestation of the mysterious
"highest frequency isnt accessable" bug, that seems to come from
some recent change in acpi.

		Dave

-- 
http://www.codemonkey.org.uk

Re: cpufreq stops working after a while

[Mark Lord]

Dave Jones wrote:
> 
> boot with cpufreq.debug=7, and capture dmesg output after it fails
> to transition.  This might be another manifestation of the mysterious
> "highest frequency isnt accessable" bug, that seems to come from
> some recent change in acpi.

booting with that option doesn't seem to give me any new messages
in dmesg (or /var/log/messages).  I also tried editing cpufreq.c
and hardcoding debug = 7 on the variable declaration.
Still no new messages.

??

Re: cpufreq stops working after a while

[Mark Lord]

Mark Lord wrote:
> Dave Jones wrote:
>>
>> boot with cpufreq.debug=7, and capture dmesg output after it fails
>> to transition.  This might be another manifestation of the mysterious
>> "highest frequency isnt accessable" bug, that seems to come from
>> some recent change in acpi.
> 
> booting with that option doesn't seem to give me any new messages
> in dmesg (or /var/log/messages).  I also tried editing cpufreq.c
> and hardcoding debug = 7 on the variable declaration.
> Still no new messages.

Mmm.. that's interesting.. this time, the scaling_max_freq went back up
to 1100000 all by itself after a longish idle period, before which it had
dropped to 800000 and got "stuck" there.

Currently using the "ondemand" governor -- it doesn't seem to call the
central cpufreq_debug_printk() thingie from cpufreq.c.

I did hack cpufreq_debug_printk() to force output anytime it gets called,
but still no new output in the logs.

Cheers

Re: cpufreq stops working after a while

[Dave Jones]

On Fri, Aug 11, 2006 at 04:01:23PM -0400, Mark Lord wrote:
 > Mark Lord wrote:
 > > Dave Jones wrote:
 > >>
 > >> boot with cpufreq.debug=7, and capture dmesg output after it fails
 > >> to transition.  This might be another manifestation of the mysterious
 > >> "highest frequency isnt accessable" bug, that seems to come from
 > >> some recent change in acpi.
 > > 
 > > booting with that option doesn't seem to give me any new messages
 > > in dmesg (or /var/log/messages).  I also tried editing cpufreq.c
 > > and hardcoding debug = 7 on the variable declaration.
 > > Still no new messages.
 > 
 > Mmm.. that's interesting.. this time, the scaling_max_freq went back up
 > to 1100000 all by itself after a longish idle period, before which it had
 > dropped to 800000 and got "stuck" there.
 > 
 > Currently using the "ondemand" governor -- it doesn't seem to call the
 > central cpufreq_debug_printk() thingie from cpufreq.c.
 > 
 > I did hack cpufreq_debug_printk() to force output anytime it gets called,
 > but still no new output in the logs.

Do you have CONFIG_CPU_FREQ_DEBUG enabled ?

		Dave
-- 
http://www.codemonkey.org.uk

Re: cpufreq stops working after a while

[Andrew Morton]

On Fri, 11 Aug 2006 14:25:26 -0400
Mark Lord <lkml@rtr.ca> wrote:

> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> 
> I use speedstep-centrino with it, and after boot all is usually okay.
> But after a few hours of operation, it stops shifting to the highest frequency
> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> and stays there until I reboot.
> 
> Sometimes rebooting doesn't even restore it.
> 
> /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
> showing the available frequencies and other info.  All of the attribs
> there look fine, except for "scaling_max_freq", which is what seems
> to gradually get set smaller.  For instance, right now it is set to 800000,
> and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.
> 
> WHY?

cpufreq seems to have relatively frequent problems.

>  And how can I fix it?

You could start by telling us which kernel versions are affected ;)

Re: cpufreq stops working after a while

[Mark Lord]

Andrew Morton wrote:
> Mark Lord <lkml@rtr.ca> wrote:
..
>> I use speedstep-centrino with it, and after boot all is usually okay.
>> But after a few hours of operation, it stops shifting to the highest frequency
>> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
>> and stays there until I reboot.
..
>> WHY?
> 
> cpufreq seems to have relatively frequent problems.
> 
>>  And how can I fix it?
> 
> You could start by telling us which kernel versions are affected ;)

Heh.  2.6.17.6 and 2.6.18-rc3-git4 are the two kernels I have for it,
and both exhibit the problem.

Dave Jones wrote:
>boot with cpufreq.debug=7, and capture dmesg output after it fails

I'll reboot with the debug options and see..

Cheers

Re: cpufreq stops working after a while

[Mark Lord]

Andrew Morton wrote:
> Mark Lord <lkml@rtr.ca> wrote:
..
>> I use speedstep-centrino with it, and after boot all is usually okay.
>> But after a few hours of operation, it stops shifting to the highest frequency
>> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
>> and stays there until I reboot.
..
>> WHY?
> 
> cpufreq seems to have relatively frequent problems.
> 
>>  And how can I fix it?
> 
> You could start by telling us which kernel versions are affected ;)

Heh.  2.6.17.6 and 2.6.18-rc3-git4 are the two kernels I have for it,
and both exhibit the problem.

Dave Jones wrote:
>boot with cpufreq.debug=7, and capture dmesg output after it fails

I'll reboot with the debug options and see..

Cheers

Re: cpufreq stops working after a while

[Mark Lord]

Andrew Morton wrote:
> On Fri, 11 Aug 2006 14:25:26 -0400
> Mark Lord <lkml@rtr.ca> wrote:
> 
>> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
>> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
>>
>> I use speedstep-centrino with it, and after boot all is usually okay.
>> But after a few hours of operation, it stops shifting to the highest frequency
>> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
>> and stays there until I reboot.
>>
>> Sometimes rebooting doesn't even restore it.
>>
>> /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
>> showing the available frequencies and other info.  All of the attribs
>> there look fine, except for "scaling_max_freq", which is what seems
>> to gradually get set smaller.  For instance, right now it is set to 800000,
>> and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.
>>
>> WHY?
> 
> cpufreq seems to have relatively frequent problems.
> 
>>  And how can I fix it?
> 
> You could start by telling us which kernel versions are affected ;)


Mmm.. since it appears to be related, kbuild dumps this out when building the kernel:

WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf29) and 'acpi_processor_cst_has_changed'

A possible source for the bug, or total red herring ?

Re: cpufreq stops working after a while

[Andrew Morton]

On Fri, 11 Aug 2006 15:10:16 -0400
Mark Lord <lkml@rtr.ca> wrote:

> >> WHY?
> > 
> > cpufreq seems to have relatively frequent problems.
> > 
> >>  And how can I fix it?
> > 
> > You could start by telling us which kernel versions are affected ;)
> 
> 
> Mmm.. since it appears to be related, kbuild dumps this out when building the kernel:
> 
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf29) and 'acpi_processor_cst_has_changed'
> 
> A possible source for the bug, or total red herring ?

An RH.  acpi_processor_power_init() is actually non-buggy, due to its
interesting games with `first_run'.

A section error would usually trigger a wild oops if you're affected by it.

Re: cpufreq stops working after a while

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 530 bytes --]

On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:

> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> 
> I use speedstep-centrino with it, and after boot all is usually okay.
> But after a few hours of operation, it stops shifting to the highest frequency
> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> and stays there until I reboot.

Can't it be TM2 pulling the handbrake?

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

Re: cpufreq stops working after a while

[Thomas Renninger]

On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> 
> > One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> > 
> > I use speedstep-centrino with it, and after boot all is usually okay.
> > But after a few hours of operation, it stops shifting to the highest frequency
> > even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> > and stays there until I reboot.

After a few hours, urgh.

Dells limit their frequency to lowest after unplugging AC and allow all
freqs after some time (some secs) again.

There were two issues solved on the Dells some months ago:

- The frequency after you unplug AC adapter is already reduced by BIOS, 
  that confused the cpufreq driver.
- There was a race in sysfs writes. If you e.g. change governor or 
  possibly some other cpufreq related sysfs file while the frequency
  got limited by BIOS, the real max freq value got overridden by the
  temporarily limited max freq value and you are stuck to lowest freq
  forever.

Do you use any userspace daemon (cpuspeed, powersaved, ...) to control
cpuspeed?
If yes, you should first try without. It should be enough to:
- load your hw cpufreq module
- load the ondemand governor module
- echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

If it still happens we know at least it can't be some kind of sysfs race
again or userspace tools do not remember the wrong max_freq value. Then
some debug output or how to reproduce this a bit faster would be nice...

Maybe with something like that:
LOAD_FACTOR=40   # adjust this one to the power of your machine to let
                 # cpufreq switch up and down, or if it does not switch 
                 # up and down in the beginning it should stay at
                 # 800 (could be 5-20 on yours?),
                 # check with (in separate console):
# cd /sys/devices/system/cpu/cpu0/cpufreq/
# watch -n1  cat scaling_cur_freq scaling_max_freq

for ((x=200;x<1000;x+=5));do
    # give load
    for ((y=0;y<$LOAD_FACTOR;y++)); do
        echo "10 k 2 v p" |dc >/dev/null
    done;
    # then sleep
    usleep $((x*1000))   # maybe the right value here triggers the bug?
    echo "sleep $x milli secs"
done;

Maybe it's triggered if you start some other process(es) while this is
running?

    Thomas

Re: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3629 bytes --]

El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> > 
> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> > > 
> > > I use speedstep-centrino with it, and after boot all is usually okay.
> > > But after a few hours of operation, it stops shifting to the highest frequency
> > > even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> > > and stays there until I reboot.

I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
Pentium(R) M processor 1.60GHz). If I'm compiling something, for
example, that takes a long time, scaling_max_freq is set to 600000 (the
lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
Only after some time if the cpu load is not high I can echoing 1600000
again and it works without need to reboot. 

> After a few hours, urgh.
> 
> Dells limit their frequency to lowest after unplugging AC and allow all
> freqs after some time (some secs) again.
> 
> There were two issues solved on the Dells some months ago:
> 
> - The frequency after you unplug AC adapter is already reduced by BIOS, 
>   that confused the cpufreq driver.
> - There was a race in sysfs writes. If you e.g. change governor or 
>   possibly some other cpufreq related sysfs file while the frequency
>   got limited by BIOS, the real max freq value got overridden by the
>   temporarily limited max freq value and you are stuck to lowest freq
>   forever.
> 
> Do you use any userspace daemon (cpuspeed, powersaved, ...) to control
> cpuspeed?

In my case I use conservative governor and kernel version is
2.6.18-rc4. 

> If yes, you should first try without. It should be enough to:
> - load your hw cpufreq module
> - load the ondemand governor module
> - echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> If it still happens we know at least it can't be some kind of sysfs race
> again or userspace tools do not remember the wrong max_freq value. Then
> some debug output or how to reproduce this a bit faster would be nice...

It happens to me every time I try to compile something that takes a long
time (evolution, mozilla, even kernel)

> Maybe with something like that:
> LOAD_FACTOR=40   # adjust this one to the power of your machine to let
>                  # cpufreq switch up and down, or if it does not switch 
>                  # up and down in the beginning it should stay at
>                  # 800 (could be 5-20 on yours?),
>                  # check with (in separate console):
> # cd /sys/devices/system/cpu/cpu0/cpufreq/
> # watch -n1  cat scaling_cur_freq scaling_max_freq
> 
> for ((x=200;x<1000;x+=5));do
>     # give load
>     for ((y=0;y<$LOAD_FACTOR;y++)); do
>         echo "10 k 2 v p" |dc >/dev/null
>     done;
>     # then sleep
>     usleep $((x*1000))   # maybe the right value here triggers the bug?
>     echo "sleep $x milli secs"
> done;
> 
> Maybe it's triggered if you start some other process(es) while this is
> running?
> 
>     Thomas
> 
> 
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@lists.linux.org.uk
> http://lists.linux.org.uk/mailman/listinfo/cpufreq

-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Mark Lord
>Sent: Friday, August 11, 2006 12:41 PM
>To: Dave Jones; Linux Kernel; Andrew Morton
>Subject: Re: cpufreq stops working after a while
>
>Dave Jones wrote:
>> 
>> boot with cpufreq.debug=7, and capture dmesg output after it fails
>> to transition.  This might be another manifestation of the mysterious
>> "highest frequency isnt accessable" bug, that seems to come from
>> some recent change in acpi.
>
>booting with that option doesn't seem to give me any new messages
>in dmesg (or /var/log/messages).  I also tried editing cpufreq.c
>and hardcoding debug = 7 on the variable declaration.
>Still no new messages.
>
>??

You also need to configure in CONFIG_CPU_FREQ_DEBUG for the parameter to
take effect.

Thanks,
Venki

Re: cpufreq stops working after a while

[Mark Lord]

Pallipadi, Venkatesh wrote:
>> Dave Jones wrote:
>>> boot with cpufreq.debug=7, and capture dmesg output after it fails
>>> to transition.  This might be another manifestation of the mysterious
>>> "highest frequency isnt accessable" bug, that seems to come from
>>> some recent change in acpi.
..
> You also need to configure in CONFIG_CPU_FREQ_DEBUG

Thanks, Venki!

Okay, here's the tail end of the trace, in which (search for "max")
one can see the top frequency limit being downgraded.

But, by whom, and why ??
And what's with these requests for oddball frequencies ("685714"),
or is that just normal approximation within the governor?


[  847.588000] speedstep-centrino: no change needed - msr was and needs to be b0c
[  847.988000] cpufreq-core: target for CPU 0: 707142 kHz, relation 0
[  847.988000] freq-table: request for target 707142 kHz (relation: 0) for cpu 0
[  847.988000] freq-table: target is 1 (800000 kHz, 2057)
[  847.988000] speedstep-centrino: target=707142kHz old=1100000 new=800000 msr=0809
[  847.988000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  847.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  847.988000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  847.988000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  847.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  848.068000] cpufreq-core: target for CPU 0: 57142 kHz, relation 0
[  848.068000] freq-table: request for target 57142 kHz (relation: 0) for cpu 0
[  848.068000] freq-table: target is 2 (600000 kHz, 1543)
[  848.068000] speedstep-centrino: target=57142kHz old=800000 new=600000 msr=0607
[  848.068000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  848.068000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.068000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  848.068000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  848.068000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.148000] cpufreq-core: target for CPU 0: 1100000 kHz, relation 1
[  848.148000] freq-table: request for target 1100000 kHz (relation: 1) for cpu 0
[  848.148000] freq-table: target is 0 (1100000 kHz, 2828)
[  848.148000] speedstep-centrino: target=1100000kHz old=600000 new=1100000 msr=0b0c
[  848.148000] cpufreq-core: notification 0 of frequency transition to 1100000 kHz
[  848.148000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  848.148000] cpufreq-core: scaling loops_per_jiffy to 4394280 for frequency 1100000 kHz
[  848.148000] cpufreq-core: notification 1 of frequency transition to 1100000 kHz
[  848.148000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  848.308000] cpufreq-core: target for CPU 0: 785714 kHz, relation 0
[  848.308000] freq-table: request for target 785714 kHz (relation: 0) for cpu 0
[  848.308000] freq-table: target is 1 (800000 kHz, 2057)
[  848.308000] speedstep-centrino: target=785714kHz old=1100000 new=800000 msr=0809
[  848.308000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  848.308000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  848.308000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  848.308000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  848.308000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  848.388000] cpufreq-core: target for CPU 0: 342857 kHz, relation 0
[  848.388000] freq-table: request for target 342857 kHz (relation: 0) for cpu 0
[  848.388000] freq-table: target is 2 (600000 kHz, 1543)
[  848.388000] speedstep-centrino: target=342857kHz old=800000 new=600000 msr=0607
[  848.388000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  848.388000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.388000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  848.388000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  848.388000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.548000] cpufreq-core: target for CPU 0: 1100000 kHz, relation 1
[  848.548000] freq-table: request for target 1100000 kHz (relation: 1) for cpu 0
[  848.548000] freq-table: target is 0 (1100000 kHz, 2828)
[  848.548000] speedstep-centrino: target=1100000kHz old=600000 new=1100000 msr=0b0c
[  848.548000] cpufreq-core: notification 0 of frequency transition to 1100000 kHz
[  848.548000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  848.548000] cpufreq-core: scaling loops_per_jiffy to 4394280 for frequency 1100000 kHz
[  848.548000] cpufreq-core: notification 1 of frequency transition to 1100000 kHz
[  848.548000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  848.788000] cpufreq-core: target for CPU 0: 157142 kHz, relation 0
[  848.788000] freq-table: request for target 157142 kHz (relation: 0) for cpu 0
[  848.788000] freq-table: target is 2 (600000 kHz, 1543)
[  848.788000] speedstep-centrino: target=157142kHz old=1100000 new=600000 msr=0607
[  848.788000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  848.788000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.788000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  848.788000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  848.788000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  848.868000] cpufreq-core: target for CPU 0: 1100000 kHz, relation 1
[  848.868000] freq-table: request for target 1100000 kHz (relation: 1) for cpu 0
[  848.868000] freq-table: target is 0 (1100000 kHz, 2828)
[  848.868000] speedstep-centrino: target=1100000kHz old=600000 new=1100000 msr=0b0c
[  848.868000] cpufreq-core: notification 0 of frequency transition to 1100000 kHz
[  848.868000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  848.868000] cpufreq-core: scaling loops_per_jiffy to 4394280 for frequency 1100000 kHz
[  848.868000] cpufreq-core: notification 1 of frequency transition to 1100000 kHz
[  848.868000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  849.188000] cpufreq-core: target for CPU 0: 550000 kHz, relation 0
[  849.188000] freq-table: request for target 550000 kHz (relation: 0) for cpu 0
[  849.188000] freq-table: target is 2 (600000 kHz, 1543)
[  849.188000] speedstep-centrino: target=550000kHz old=1100000 new=600000 msr=0607
[  849.188000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  849.188000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  849.188000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  849.188000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  849.188000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  849.348000] cpufreq-core: target for CPU 0: 1100000 kHz, relation 1
[  849.348000] freq-table: request for target 1100000 kHz (relation: 1) for cpu 0
[  849.348000] freq-table: target is 0 (1100000 kHz, 2828)
[  849.348000] speedstep-centrino: target=1100000kHz old=600000 new=1100000 msr=0b0c
[  849.348000] cpufreq-core: notification 0 of frequency transition to 1100000 kHz
[  849.348000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  849.348000] cpufreq-core: scaling loops_per_jiffy to 4394280 for frequency 1100000 kHz
[  849.348000] cpufreq-core: notification 1 of frequency transition to 1100000 kHz
[  849.348000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  852.148000] cpufreq-core: target for CPU 0: 707142 kHz, relation 0
[  852.148000] freq-table: request for target 707142 kHz (relation: 0) for cpu 0
[  852.148000] freq-table: target is 1 (800000 kHz, 2057)
[  852.148000] speedstep-centrino: target=707142kHz old=1100000 new=800000 msr=0809
[  852.148000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  852.148000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  852.148000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  852.148000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  852.148000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  852.228000] cpufreq-core: target for CPU 0: 57142 kHz, relation 0
[  852.228000] freq-table: request for target 57142 kHz (relation: 0) for cpu 0
[  852.228000] freq-table: target is 2 (600000 kHz, 1543)
[  852.228000] speedstep-centrino: target=57142kHz old=800000 new=600000 msr=0607
[  852.228000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  852.228000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  852.228000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  852.228000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  852.228000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  852.468000] cpufreq-core: target for CPU 0: 1100000 kHz, relation 1
[  852.468000] freq-table: request for target 1100000 kHz (relation: 1) for cpu 0
[  852.468000] freq-table: target is 0 (1100000 kHz, 2828)
[  852.468000] speedstep-centrino: target=1100000kHz old=600000 new=1100000 msr=0b0c
[  852.468000] cpufreq-core: notification 0 of frequency transition to 1100000 kHz
[  852.468000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  852.468000] cpufreq-core: scaling loops_per_jiffy to 4394280 for frequency 1100000 kHz
[  852.468000] cpufreq-core: notification 1 of frequency transition to 1100000 kHz
[  852.468000] userspace: saving cpu_cur_freq of cpu 0 to be 1100000 kHz
[  853.228000] cpufreq-core: updating policy for CPU 0
[  853.228000] cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1100000, is 800000 kHz.
[  853.228000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  853.228000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  853.228000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  853.228000] cpufreq-core: setting new policy for CPU 0: 600000 - 1100000 kHz
[  853.228000] freq-table: request for verification of policy (600000 - 1100000 kHz) for cpu 0
[  853.228000] freq-table: verification lead to (600000 - 1100000 kHz) for cpu 0
[  853.228000] freq-table: request for verification of policy (600000 - 800000 kHz) for cpu 0
[  853.228000] freq-table: verification lead to (600000 - 800000 kHz) for cpu 0
[  853.228000] cpufreq-core: new min and max freqs are 600000 - 800000 kHz
[  853.228000] cpufreq-core: governor: change or update limits
[  853.228000] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[  854.308000] cpufreq-core: target for CPU 0: 685714 kHz, relation 0
[  854.308000] freq-table: request for target 685714 kHz (relation: 0) for cpu 0
[  854.308000] freq-table: target is 1 (800000 kHz, 2057)
[  854.308000] speedstep-centrino: no change needed - msr was and needs to be 809
[  854.388000] cpufreq-core: target for CPU 0: 342857 kHz, relation 0
[  854.388000] freq-table: request for target 342857 kHz (relation: 0) for cpu 0
[  854.388000] freq-table: target is 2 (600000 kHz, 1543)
[  854.388000] speedstep-centrino: target=342857kHz old=800000 new=600000 msr=0607
[  854.388000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  854.388000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  854.388000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  854.388000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  854.388000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  854.548000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  854.548000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  854.548000] freq-table: target is 1 (800000 kHz, 2057)
[  854.548000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  854.548000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  854.548000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  854.548000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  854.548000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  854.548000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  855.988000] cpufreq-core: target for CPU 0: 57142 kHz, relation 0
[  855.988000] freq-table: request for target 57142 kHz (relation: 0) for cpu 0
[  855.988000] freq-table: target is 2 (600000 kHz, 1543)
[  855.988000] speedstep-centrino: target=57142kHz old=800000 new=600000 msr=0607
[  855.988000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  855.988000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  855.988000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  855.988000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  855.988000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  856.228000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  856.228000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  856.228000] freq-table: target is 1 (800000 kHz, 2057)
[  856.228000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  856.228000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  856.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  856.228000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  856.228000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  856.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  856.628000] cpufreq-core: target for CPU 0: 285714 kHz, relation 0
[  856.628000] freq-table: request for target 285714 kHz (relation: 0) for cpu 0
[  856.628000] freq-table: target is 2 (600000 kHz, 1543)
[  856.628000] speedstep-centrino: target=285714kHz old=800000 new=600000 msr=0607
[  856.628000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  856.628000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  856.628000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  856.628000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  856.628000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  856.788000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  856.788000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  856.788000] freq-table: target is 1 (800000 kHz, 2057)
[  856.788000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  856.788000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  856.788000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  856.788000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  856.788000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  856.788000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  857.588000] cpufreq-core: target for CPU 0: 571428 kHz, relation 0
[  857.588000] freq-table: request for target 571428 kHz (relation: 0) for cpu 0
[  857.588000] freq-table: target is 2 (600000 kHz, 1543)
[  857.588000] speedstep-centrino: target=571428kHz old=800000 new=600000 msr=0607
[  857.588000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  857.588000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  857.588000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  857.588000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  857.588000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  857.668000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  857.668000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  857.668000] freq-table: target is 1 (800000 kHz, 2057)
[  857.668000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  857.668000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  857.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  857.668000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  857.668000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  857.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  861.908000] cpufreq-core: target for CPU 0: 457142 kHz, relation 0
[  861.908000] freq-table: request for target 457142 kHz (relation: 0) for cpu 0
[  861.908000] freq-table: target is 2 (600000 kHz, 1543)
[  861.908000] speedstep-centrino: target=457142kHz old=800000 new=600000 msr=0607
[  861.908000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  861.908000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  861.908000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  861.908000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  861.908000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  861.988000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  861.988000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  861.988000] freq-table: target is 1 (800000 kHz, 2057)
[  861.988000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  861.988000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  861.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  861.988000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  861.988000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  861.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  865.588000] cpufreq-core: target for CPU 0: 342857 kHz, relation 0
[  865.588000] freq-table: request for target 342857 kHz (relation: 0) for cpu 0
[  865.588000] freq-table: target is 2 (600000 kHz, 1543)
[  865.588000] speedstep-centrino: target=342857kHz old=800000 new=600000 msr=0607
[  865.588000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  865.588000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  865.588000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  865.588000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  865.588000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  865.668000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  865.668000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  865.668000] freq-table: target is 1 (800000 kHz, 2057)
[  865.668000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  865.668000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  865.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  865.668000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  865.668000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  865.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  865.748000] cpufreq-core: target for CPU 0: 742857 kHz, relation 0
[  865.748000] freq-table: request for target 742857 kHz (relation: 0) for cpu 0
[  865.748000] freq-table: target is 1 (800000 kHz, 2057)
[  865.748000] speedstep-centrino: no change needed - msr was and needs to be 809
[  865.828000] cpufreq-core: target for CPU 0: 285714 kHz, relation 0
[  865.828000] freq-table: request for target 285714 kHz (relation: 0) for cpu 0
[  865.828000] freq-table: target is 2 (600000 kHz, 1543)
[  865.828000] speedstep-centrino: target=285714kHz old=800000 new=600000 msr=0607
[  865.828000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  865.828000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  865.828000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  865.828000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  865.828000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  865.988000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  865.988000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  865.988000] freq-table: target is 1 (800000 kHz, 2057)
[  865.988000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  865.988000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  865.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  865.988000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  865.988000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  865.988000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  866.948000] cpufreq-core: target for CPU 0: 742857 kHz, relation 0
[  866.948000] freq-table: request for target 742857 kHz (relation: 0) for cpu 0
[  866.948000] freq-table: target is 1 (800000 kHz, 2057)
[  866.948000] speedstep-centrino: no change needed - msr was and needs to be 809
[  871.428000] cpufreq-core: target for CPU 0: 571428 kHz, relation 0
[  871.428000] freq-table: request for target 571428 kHz (relation: 0) for cpu 0
[  871.428000] freq-table: target is 2 (600000 kHz, 1543)
[  871.428000] speedstep-centrino: target=571428kHz old=800000 new=600000 msr=0607
[  871.428000] cpufreq-core: notification 0 of frequency transition to 600000 kHz
[  871.428000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  871.428000] cpufreq-core: notification 1 of frequency transition to 600000 kHz
[  871.428000] cpufreq-core: scaling loops_per_jiffy to 2396880 for frequency 600000 kHz
[  871.428000] userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
[  871.668000] cpufreq-core: target for CPU 0: 800000 kHz, relation 1
[  871.668000] freq-table: request for target 800000 kHz (relation: 1) for cpu 0
[  871.668000] freq-table: target is 1 (800000 kHz, 2057)
[  871.668000] speedstep-centrino: target=800000kHz old=600000 new=800000 msr=0809
[  871.668000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[  871.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  871.668000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[  871.668000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[  871.668000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[  874.948000] cpufreq-core: target for CPU 0: 628571 kHz, relation 0
[  874.948000] freq-table: request for target 628571 kHz (relation: 0) for cpu 0
[  874.948000] freq-table: target is 1 (800000 kHz, 2057)
[  874.948000] speedstep-centrino: no change needed - msr was and needs to be 809
silvy:~#                                                                                      

Re: cpufreq stops working after a while

[Mark Lord]

Ahhh...

>From the trace, I see a bunch of "userspace" lines appearing.
And sure enough, something called "powernowd" is running,
and probably conflicting with the "ondemand" governor.

I'm nuking powernowd, and that'll probably cure it for this box.
I guess the distro (kubuntu) must have started "powernowd"
even though I told it (the distro) to use "ondemand".

Does it make sense that this could change the upper limit, though?

Thanks guys!

Re: cpufreq stops working after a while

[Dave Jones]

On Fri, Aug 11, 2006 at 04:39:19PM -0400, Mark Lord wrote:
 > Ahhh...
 > 
 > >From the trace, I see a bunch of "userspace" lines appearing.
 > And sure enough, something called "powernowd" is running,
 > and probably conflicting with the "ondemand" governor.

It'll override it, you can't run both at the same time.
Well, unless you have a dual-core/multi-cpu system, where you
could have a different governor per-core. But that would be loony,
and we should probably disallow that possibility before someone
gets any bright ideas.

Looking at your log however, you only have a single CPU, so it'll
be using userspace exclusively.

 > I'm nuking powernowd, and that'll probably cure it for this box.
 > I guess the distro (kubuntu) must have started "powernowd"
 > even though I told it (the distro) to use "ondemand".
 > 
 > Does it make sense that this could change the upper limit, though?

A userspace governor can pretty much invent its own rules. I'm not
familiar with what constraints powernowd has.  It may even have
limits defined in a config file someplace.

Is it behaving again with ondemand ?

		Dave

-- 
http://www.codemonkey.org.uk

Re: cpufreq stops working after a while

[Mark Lord]

Dave Jones wrote:
>
> A userspace governor can pretty much invent its own rules. I'm not
> familiar with what constraints powernowd has.  It may even have
> limits defined in a config file someplace.
> 
> Is it behaving again with ondemand ?

So far, so good, thanks.

I seem to recall having killed off powernowd when I first installed
the system here, but perhaps a subsequent update reenabled it again.

Bah!

Cheers

Re: cpufreq stops working after a while

[Mark Lord]

Mmm.. spoke too soon.

I have not actually rebooted since killing powernowd,
and it just happened again now.  No powernowd running.

Limit dropped from 1100Mhz to 800Mhz (log below).

> Venki wrote:
> Looks like there are thermal events happening that is causing CPU limits
> to reduce. Are you running anything on the CPU when this happens. Is
> there a thermal interface in /proc/acpi that can give you the current
> temperature of the system?


There are thermal thingies in /proc, and I'm watching the temperature
value from there (62C --> 65C), and the trip_points value is 95C..

Think it's thermal?

Re: cpufreq stops working after a while

[Mark Lord]

Mark Lord wrote:
> Mmm.. spoke too soon.
> 
> I have not actually rebooted since killing powernowd,
> and it just happened again now.  No powernowd running.
> 
> Limit dropped from 1100Mhz to 800Mhz (log below).

Again.. with the log..


[ 3608.828000] cpufreq-core: updating policy for CPU 0
[ 3608.828000] cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1100000, is 800000 kHz.
[ 3608.828000] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[ 3608.828000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[ 3608.828000] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[ 3608.828000] cpufreq-core: scaling loops_per_jiffy to 3195840 for frequency 800000 kHz
[ 3608.828000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
[ 3608.828000] cpufreq-core: setting new policy for CPU 0: 600000 - 1100000 kHz
[ 3608.828000] freq-table: request for verification of policy (600000 - 1100000 kHz) for cpu 0
[ 3608.828000] freq-table: verification lead to (600000 - 1100000 kHz) for cpu 0
[ 3608.828000] freq-table: request for verification of policy (600000 - 800000 kHz) for cpu 0
[ 3608.828000] freq-table: verification lead to (600000 - 800000 kHz) for cpu 0
[ 3608.828000] cpufreq-core: new min and max freqs are 600000 - 800000 kHz
[ 3608.828000] cpufreq-core: governor: change or update limits
[ 3608.828000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

Re: cpufreq stops working after a while

[Mark Lord]

Mark Lord wrote:
>
>> Venki wrote:
>> Looks like there are thermal events happening that is causing CPU limits
>> to reduce. Are you running anything on the CPU when this happens. Is
>> there a thermal interface in /proc/acpi that can give you the current
>> temperature of the system?
> 
> There are thermal thingies in /proc, and I'm watching the temperature
> value from there (62C --> 65C), and the trip_points value is 95C..
> 
> Think it's thermal?

Yup, thermal.
Trips shortly after I see 66C in /proc/acpi/thermal_zone/THM/temperature

If I stop number crunching for a bit, the temperature drops down to the
low 50's, and the max freq then gets set back to 1100.

Mmmm.. is there a way to control the high/low thermostat values there?

Cheers

Re: cpufreq stops working after a while

[Pavel Machek]

Hi!

> >There are thermal thingies in /proc, and I'm watching 
> >the temperature
> >value from there (62C --> 65C), and the trip_points 
> >value is 95C..
> >
> >Think it's thermal?
> 
> Yup, thermal.
> Trips shortly after I see 66C in 
> /proc/acpi/thermal_zone/THM/temperature
> 
> If I stop number crunching for a bit, the temperature 
> drops down to the
> low 50's, and the max freq then gets set back to 1100.
> 
> Mmmm.. is there a way to control the high/low thermostat 
> values there?

trip_points should be writeable... but you do not have passive cooling
enabled there?!

-- 
Thanks for all the (sleeping) penguins.

Re: cpufreq stops working after a while

[Mark Lord]

Pavel Machek wrote:
>
> trip_points should be writeable... but you do not have passive cooling
> enabled there?!

What do you mean -- I don't understand what you were trying to say
(probably just a language thing).

By definition, "passive" cooling never needs enabling -- this just refers
to things like heat sinks and air vents.

"Active" cooling is the term for fans and pumps and such.

Cheers

Re: cpufreq stops working after a while

[Matthew Garrett]

On Thu, Aug 24, 2006 at 10:44:28AM -0400, Mark Lord wrote:

> By definition, "passive" cooling never needs enabling -- this just refers
> to things like heat sinks and air vents.

In ACPI terms, passive cooling is forced downthrottling of the CPU in 
order to reduce heat generation. This is normally done if the 
temperature is continuing to rise despite active cooling being enabled.

On some hardware you can set the values at which different types of 
cooling will be enabled in /proc/acpi/thermal_zone/*/trip_points. Echo a 
colon separated list of values in there to rewrite them. Some BIOSes 
will change the trip points in response to various events, which will 
then overwrite your values.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Mark Lord [mailto:lkml@rtr.ca] 
>Sent: Friday, August 11, 2006 1:30 PM
>To: Dave Jones
>Cc: Pallipadi, Venkatesh; Linux Kernel; Andrew Morton
>Subject: Re: cpufreq stops working after a while
>
>Pallipadi, Venkatesh wrote:
>>> Dave Jones wrote:
>>>> boot with cpufreq.debug=7, and capture dmesg output after it fails
>>>> to transition.  This might be another manifestation of the 
>mysterious
>>>> "highest frequency isnt accessable" bug, that seems to come from
>>>> some recent change in acpi.
>..
>> You also need to configure in CONFIG_CPU_FREQ_DEBUG
>
>Thanks, Venki!
>
>Okay, here's the tail end of the trace, in which (search for "max")
>one can see the top frequency limit being downgraded.
>
>But, by whom, and why ??
>And what's with these requests for oddball frequencies ("685714"),
>or is that just normal approximation within the governor?
>
>
>[  853.228000] cpufreq-core: updating policy for CPU 0
>[  853.228000] cpufreq-core: Warning: CPU frequency out of 
>sync: cpufreq and timing core thinks of 1100000, is 800000 kHz.
>[  853.228000] cpufreq-core: notification 0 of frequency 
>transition to 800000 kHz
>[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
>[  853.228000] cpufreq-core: notification 1 of frequency 
>transition to 800000 kHz
>[  853.228000] cpufreq-core: scaling loops_per_jiffy to 
>3195840 for frequency 800000 kHz
>[  853.228000] userspace: saving cpu_cur_freq of cpu 0 to be 800000 kHz
>[  853.228000] cpufreq-core: setting new policy for CPU 0: 
>600000 - 1100000 kHz
>[  853.228000] freq-table: request for verification of policy 
>(600000 - 1100000 kHz) for cpu 0
>[  853.228000] freq-table: verification lead to (600000 - 
>1100000 kHz) for cpu 0
>[  853.228000] freq-table: request for verification of policy 
>(600000 - 800000 kHz) for cpu 0
>[  853.228000] freq-table: verification lead to (600000 - 
>800000 kHz) for cpu 0
>[  853.228000] cpufreq-core: new min and max freqs are 600000 
>- 800000 kHz
>[  853.228000] cpufreq-core: governor: change or update limits
>[  853.228000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

Looks like there are thermal events happening that is causing CPU limits
to reduce. Are you running anything on the CPU when this happens. Is
there a thermal interface in /proc/acpi that can give you the current
temperature of the system?

Thanks,
Venki

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Mark Lord [mailto:lkml@rtr.ca] 
>Sent: Friday, August 11, 2006 2:25 PM
>To: Pallipadi, Venkatesh
>Cc: Dave Jones; Linux Kernel; Andrew Morton
>Subject: Re: cpufreq stops working after a while
>
>Mark Lord wrote:
>>
>>> Venki wrote:
>>> Looks like there are thermal events happening that is 
>causing CPU limits
>>> to reduce. Are you running anything on the CPU when this happens. Is
>>> there a thermal interface in /proc/acpi that can give you 
>the current
>>> temperature of the system?
>> 
>> There are thermal thingies in /proc, and I'm watching the temperature
>> value from there (62C --> 65C), and the trip_points value is 95C..
>> 
>> Think it's thermal?
>
>Yup, thermal.
>Trips shortly after I see 66C in 
>/proc/acpi/thermal_zone/THM/temperature
>
>If I stop number crunching for a bit, the temperature drops down to the
>low 50's, and the max freq then gets set back to 1100.
>
>Mmmm.. is there a way to control the high/low thermostat values there?
>
>Cheers

What is the "cooling mode" you have in
/proc/acpi/thermal_zone/THM/cooling_mode.
Output of all files in that directory will help.

Thanks,
Venki

Re: cpufreq stops working after a while

[Mark Lord]

Pallipadi, Venkatesh wrote:
>> Mark Lord wrote:
>> Yup, thermal.
>> Trips shortly after I see 66C in 
>> /proc/acpi/thermal_zone/THM/temperature
>>
>> If I stop number crunching for a bit, the temperature drops down to the
>> low 50's, and the max freq then gets set back to 1100.
>>
>> Mmmm.. is there a way to control the high/low thermostat values there?
..
> What is the "cooling mode" you have in
> /proc/acpi/thermal_zone/THM/cooling_mode.
> Output of all files in that directory will help.

/proc/acpi/thermal_zone/THM/cooling_mode:
	<setting not supported>
	cooling mode:   critical

/proc/acpi/thermal_zone/THM/polling_frequency:
	<polling disabled>

/proc/acpi/thermal_zone/THM/state:
	state:                   ok

/proc/acpi/thermal_zone/THM/temperature:
	temperature:             49 C

/proc/acpi/thermal_zone/THM/trip_points:
	critical (S5):           95 C

==========

This is a passively cooled notebook, so there's no fan
to control.  They probably self-limit the CPU speed when
the temperature gets high to prevent meltdown of the drive.

But I would like to raise the lower limit if possible,
allowing the speed to bump back up at, say 58C rather
than waiting for 52C as it currently does.

??

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Mark Lord [mailto:lkml@rtr.ca] 
>Sent: Friday, August 11, 2006 2:54 PM
>To: Pallipadi, Venkatesh
>Cc: Dave Jones; Linux Kernel; Andrew Morton
>Subject: Re: cpufreq stops working after a while
>
>Pallipadi, Venkatesh wrote:
>>> Mark Lord wrote:
>>> Yup, thermal.
>>> Trips shortly after I see 66C in 
>>> /proc/acpi/thermal_zone/THM/temperature
>>>
>>> If I stop number crunching for a bit, the temperature drops 
>down to the
>>> low 50's, and the max freq then gets set back to 1100.
>>>
>>> Mmmm.. is there a way to control the high/low thermostat 
>values there?
>..
>> What is the "cooling mode" you have in
>> /proc/acpi/thermal_zone/THM/cooling_mode.
>> Output of all files in that directory will help.
>
>/proc/acpi/thermal_zone/THM/cooling_mode:
>	<setting not supported>
>	cooling mode:   critical
>
>/proc/acpi/thermal_zone/THM/polling_frequency:
>	<polling disabled>
>
>/proc/acpi/thermal_zone/THM/state:
>	state:                   ok
>
>/proc/acpi/thermal_zone/THM/temperature:
>	temperature:             49 C
>
>/proc/acpi/thermal_zone/THM/trip_points:
>	critical (S5):           95 C
>
>==========
>
>This is a passively cooled notebook, so there's no fan
>to control.  They probably self-limit the CPU speed when
>the temperature gets high to prevent meltdown of the drive.
>
>But I would like to raise the lower limit if possible,
>allowing the speed to bump back up at, say 58C rather
>than waiting for 52C as it currently does.
>
>??

Passive cooling starting temperature is given by platform manufacturer
through BIOS. You can check whether your BIOS has any option to change
it. Changing it manually by custom DSDT etc may be risky :).
One thing you can try from software is the polling_frequency above. For
some reason it is set to zero above. Try setting it to 1 sec and see
whether that makes any difference (echo 1 >
/proc/acpi/thermal_zone/THM/polling_frequency).

Venki

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Carlos Garcia Campos
>Sent: Tuesday, August 15, 2006 4:07 AM
>To: cpufreq@lists.linux.org.uk
>Subject: Re: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
>> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
>> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
>> > 
>> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz 
>Pentium-M ULV processor.
>> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
>> > > 
>> > > I use speedstep-centrino with it, and after boot all is 
>usually okay.
>> > > But after a few hours of operation, it stops shifting to 
>the highest frequency
>> > > even under continuous 100% load (or not).  Eventually it 
>gets stuck at 600Mhz
>> > > and stays there until I reboot.
>
>I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
>Pentium(R) M processor 1.60GHz). If I'm compiling something, for
>example, that takes a long time, scaling_max_freq is set to 600000 (the
>lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
>Only after some time if the cpu load is not high I can echoing 1600000
>again and it works without need to reboot. 
>

Looks like you have the same problem that Mark had in this original thread. Thermal.
It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 2612 bytes --]

El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk 
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >Carlos Garcia Campos
> >Sent: Tuesday, August 15, 2006 4:07 AM
> >To: cpufreq@lists.linux.org.uk
> >Subject: Re: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
> >> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> >> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> >> > 
> >> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz 
> >Pentium-M ULV processor.
> >> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> >> > > 
> >> > > I use speedstep-centrino with it, and after boot all is 
> >usually okay.
> >> > > But after a few hours of operation, it stops shifting to 
> >the highest frequency
> >> > > even under continuous 100% load (or not).  Eventually it 
> >gets stuck at 600Mhz
> >> > > and stays there until I reboot.
> >
> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >example, that takes a long time, scaling_max_freq is set to 600000 (the
> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >Only after some time if the cpu load is not high I can echoing 1600000
> >again and it works without need to reboot. 
> >
> 
> Looks like you have the same problem that Mark had in this original thread. Thermal.

It never happened with older kernels (< 2.6.17, I think)

> It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

Yes, my system has fans. Here is the contents of the files
under /proc/acpi/termal_zone/*/*, if it helps:

$ cat /proc/acpi/thermal_zone/THM/*
<setting not supported>
cooling mode:   critical
<polling disabled>
state:                   ok
temperature:             47 C
critical (S5):           102 C

How can I solve the problem then? It's very annoying. 

> Thanks,
> Venki
> 

Thanks a lot, 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

Re: cpufreq stops working after a while

[Len Brown]

> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >example, that takes a long time, scaling_max_freq is set to 600000 (the
> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >Only after some time if the cpu load is not high I can echoing 1600000
> >again and it works without need to reboot. 
> >
> 
> Looks like you have the same problem that Mark had in this original thread. Thermal.
> It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

I've got a D600 and have noticed thermal throttling also.
The way I noticed it is because bltk showed poor performance
compared to other similar laptops when measuring battery life:

http://sourceforge.net/projects/bltk
 
I found that this was independent of cpufreq, and would still happen even if the performance governor was used.
Sometimes I noticed that the T-state in /proc/acpi/processor/*/throttling was not 0, which was unexpected.

I blamed SuSE's stupid powersavd at the time (IIR, it was SL10.1) , but maybe that wasn't the root cause.

-Len

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
>Sent: Tuesday, August 15, 2006 8:08 AM
>To: Pallipadi, Venkatesh
>Cc: cpufreq@lists.linux.org.uk
>Subject: RE: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>>  
>> >-----Original Message-----
>> >From: cpufreq-bounces@lists.linux.org.uk 
>> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>> >Carlos Garcia Campos
>> >Sent: Tuesday, August 15, 2006 4:07 AM
>> >To: cpufreq@lists.linux.org.uk
>> >Subject: Re: cpufreq stops working after a while
>> >
>> >
>> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
>> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
>> >example, that takes a long time, scaling_max_freq is set to 
>600000 (the
>> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
>> >Only after some time if the cpu load is not high I can 
>echoing 1600000
>> >again and it works without need to reboot. 
>> >
>> 
>> Looks like you have the same problem that Mark had in this 
>original thread. Thermal.
>
>It never happened with older kernels (< 2.6.17, I think)
>

Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.

>> It is not a bug in cpufreq. Just that due to cpu load, 
>system is getting heated up and platform decides to reduce the 
>temperature using passive cooling and as a result reduces the 
>frequency. Does your system have active cooling (fans) or does 
>it allow only passive cooling? You can monitor the temperature 
>by looking at stuff under /proc/acpi/termal_zone/*/*.
>
>Yes, my system has fans. Here is the contents of the files
>under /proc/acpi/termal_zone/*/*, if it helps:
>
>$ cat /proc/acpi/thermal_zone/THM/*
><setting not supported>
>cooling mode:   critical
><polling disabled>
>state:                   ok
>temperature:             47 C
>critical (S5):           102 C
>
>How can I solve the problem then? It's very annoying. 


Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.


Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3078 bytes --]

El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
> >Sent: Tuesday, August 15, 2006 8:08 AM
> >To: Pallipadi, Venkatesh
> >Cc: cpufreq@lists.linux.org.uk
> >Subject: RE: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >>  
> >> >-----Original Message-----
> >> >From: cpufreq-bounces@lists.linux.org.uk 
> >> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >> >Carlos Garcia Campos
> >> >Sent: Tuesday, August 15, 2006 4:07 AM
> >> >To: cpufreq@lists.linux.org.uk
> >> >Subject: Re: cpufreq stops working after a while
> >> >
> >> >
> >> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >> >example, that takes a long time, scaling_max_freq is set to 
> >600000 (the
> >> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >> >Only after some time if the cpu load is not high I can 
> >echoing 1600000
> >> >again and it works without need to reboot. 
> >> >
> >> 
> >> Looks like you have the same problem that Mark had in this 
> >original thread. Thermal.
> >
> >It never happened with older kernels (< 2.6.17, I think)
> >
> 
> Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.

I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
right now.

> >> It is not a bug in cpufreq. Just that due to cpu load, 
> >system is getting heated up and platform decides to reduce the 
> >temperature using passive cooling and as a result reduces the 
> >frequency. Does your system have active cooling (fans) or does 
> >it allow only passive cooling? You can monitor the temperature 
> >by looking at stuff under /proc/acpi/termal_zone/*/*.
> >
> >Yes, my system has fans. Here is the contents of the files
> >under /proc/acpi/termal_zone/*/*, if it helps:
> >
> >$ cat /proc/acpi/thermal_zone/THM/*
> ><setting not supported>
> >cooling mode:   critical
> ><polling disabled>
> >state:                   ok
> >temperature:             47 C
> >critical (S5):           102 C
> >
> >How can I solve the problem then? It's very annoying. 
> 
> 
> Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.

Here are the results:

................
1600000 - 85 C
1600000 - 84 C
1600000 - 85 C
1600000 - 76 C
600000 - 76 C
600000 - 71 C
600000 - 70 C
600000 - 69 C
................

It changed at 76 C.

> 
> Thanks,
> Venki
> 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3578 bytes --]

El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
> >  
> > >-----Original Message-----
> > >From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
> > >Sent: Tuesday, August 15, 2006 8:08 AM
> > >To: Pallipadi, Venkatesh
> > >Cc: cpufreq@lists.linux.org.uk
> > >Subject: RE: cpufreq stops working after a while
> > >
> > >El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> > >>  
> > >> >-----Original Message-----
> > >> >From: cpufreq-bounces@lists.linux.org.uk 
> > >> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> > >> >Carlos Garcia Campos
> > >> >Sent: Tuesday, August 15, 2006 4:07 AM
> > >> >To: cpufreq@lists.linux.org.uk
> > >> >Subject: Re: cpufreq stops working after a while
> > >> >
> > >> >
> > >> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> > >> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> > >> >example, that takes a long time, scaling_max_freq is set to 
> > >600000 (the
> > >> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> > >> >Only after some time if the cpu load is not high I can 
> > >echoing 1600000
> > >> >again and it works without need to reboot. 
> > >> >
> > >> 
> > >> Looks like you have the same problem that Mark had in this 
> > >original thread. Thermal.
> > >
> > >It never happened with older kernels (< 2.6.17, I think)
> > >
> > 
> > Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.
> 
> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
> right now.
> 
> > >> It is not a bug in cpufreq. Just that due to cpu load, 
> > >system is getting heated up and platform decides to reduce the 
> > >temperature using passive cooling and as a result reduces the 
> > >frequency. Does your system have active cooling (fans) or does 
> > >it allow only passive cooling? You can monitor the temperature 
> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
> > >
> > >Yes, my system has fans. Here is the contents of the files
> > >under /proc/acpi/termal_zone/*/*, if it helps:
> > >
> > >$ cat /proc/acpi/thermal_zone/THM/*
> > ><setting not supported>
> > >cooling mode:   critical
> > ><polling disabled>
> > >state:                   ok
> > >temperature:             47 C
> > >critical (S5):           102 C
> > >
> > >How can I solve the problem then? It's very annoying. 
> > 
> > 
> > Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.
> 
> Here are the results:
> 
> ................
> 1600000 - 85 C
> 1600000 - 84 C
> 1600000 - 85 C
> 1600000 - 76 C
> 600000 - 76 C
> 600000 - 71 C
> 600000 - 70 C
> 600000 - 69 C
> ................
> 
> It changed at 76 C.

I forgot to mention that if I boot from battery scaling_max_freq is set
to 600000 and I have to echo 1600000. At boot time temperature is not
high so I'm not sure it's a thermal problem, or at least not only a
thermal problem. 

> > 
> > Thanks,
> > Venki
> > 

Thanks a lot for your help,
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Carlos Garcia Campos
>Sent: Wednesday, August 16, 2006 3:11 AM
>To: cpufreq@lists.linux.org.uk
>Subject: RE: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
>> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
>> >  
>> > 
>> > Can you confirm the latest version of the kernel where the 
>problem was not there. That will help on narrowing this down.
>> 
>> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
>> right now.
>> 
>> > >> It is not a bug in cpufreq. Just that due to cpu load, 
>> > >system is getting heated up and platform decides to reduce the 
>> > >temperature using passive cooling and as a result reduces the 
>> > >frequency. Does your system have active cooling (fans) or does 
>> > >it allow only passive cooling? You can monitor the temperature 
>> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
>> > >
>> > >Yes, my system has fans. Here is the contents of the files
>> > >under /proc/acpi/termal_zone/*/*, if it helps:
>> > >
>> > >$ cat /proc/acpi/thermal_zone/THM/*
>> > ><setting not supported>
>> > >cooling mode:   critical
>> > ><polling disabled>
>> > >state:                   ok
>> > >temperature:             47 C
>> > >critical (S5):           102 C
>> > >
>> > >How can I solve the problem then? It's very annoying. 
>> > 
>> > 
>> > Can you watch the temperature as you see the frequency 
>drop. Continuously (every second) cat cpufreq_max_freq in /sys 
>and temperature in /proc as you run you load. My feeling is 
>you will see the drop in max freq as your temperature goes to 
>around 60 degrees or so.
>> 
>> Here are the results:
>> 
>> ................
>> 1600000 - 85 C
>> 1600000 - 84 C
>> 1600000 - 85 C
>> 1600000 - 76 C
>> 600000 - 76 C
>> 600000 - 71 C
>> 600000 - 70 C
>> 600000 - 69 C
>> ................
>> 
>> It changed at 76 C.
>
>I forgot to mention that if I boot from battery scaling_max_freq is set
>to 600000 and I have to echo 1600000. At boot time temperature is not
>high so I'm not sure it's a thermal problem, or at least not only a
>thermal problem. 
>

That looks like a different problem. It may be a policy being set by some userland daemon/startup script. Enable CPU_FREQ_DEBUG and boot with boot parameter cpufreq.debug=7 you should see when and why max_freq is changing. Infact for the other problem as well, get the messages from debug.

One other thing you can try is changing thermal_zone polling_frequency to 1 and see whether it change the behavior when you run the workload.

Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 6336 bytes --]

El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk 
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >Carlos Garcia Campos
> >Sent: Wednesday, August 16, 2006 3:11 AM
> >To: cpufreq@lists.linux.org.uk
> >Subject: RE: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
> >> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
> >> >  
> >> > 
> >> > Can you confirm the latest version of the kernel where the 
> >problem was not there. That will help on narrowing this down.
> >> 
> >> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
> >> right now.
> >> 
> >> > >> It is not a bug in cpufreq. Just that due to cpu load, 
> >> > >system is getting heated up and platform decides to reduce the 
> >> > >temperature using passive cooling and as a result reduces the 
> >> > >frequency. Does your system have active cooling (fans) or does 
> >> > >it allow only passive cooling? You can monitor the temperature 
> >> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
> >> > >
> >> > >Yes, my system has fans. Here is the contents of the files
> >> > >under /proc/acpi/termal_zone/*/*, if it helps:
> >> > >
> >> > >$ cat /proc/acpi/thermal_zone/THM/*
> >> > ><setting not supported>
> >> > >cooling mode:   critical
> >> > ><polling disabled>
> >> > >state:                   ok
> >> > >temperature:             47 C
> >> > >critical (S5):           102 C
> >> > >
> >> > >How can I solve the problem then? It's very annoying. 
> >> > 
> >> > 
> >> > Can you watch the temperature as you see the frequency 
> >drop. Continuously (every second) cat cpufreq_max_freq in /sys 
> >and temperature in /proc as you run you load. My feeling is 
> >you will see the drop in max freq as your temperature goes to 
> >around 60 degrees or so.
> >> 
> >> Here are the results:
> >> 
> >> ................
> >> 1600000 - 85 C
> >> 1600000 - 84 C
> >> 1600000 - 85 C
> >> 1600000 - 76 C
> >> 600000 - 76 C
> >> 600000 - 71 C
> >> 600000 - 70 C
> >> 600000 - 69 C
> >> ................
> >> 
> >> It changed at 76 C.
> >
> >I forgot to mention that if I boot from battery scaling_max_freq is set
> >to 600000 and I have to echo 1600000. At boot time temperature is not
> >high so I'm not sure it's a thermal problem, or at least not only a
> >thermal problem. 
> >
> 
> That looks like a different problem. It may be a policy being set by some userland daemon/startup script. Enable CPU_FREQ_DEBUG and boot with boot parameter cpufreq.debug=7 you should see when and why max_freq is changing. Infact for the other problem as well, get the messages from debug.

I have a script in /etc/init.d to set conservative governor at startup. 

> One other thing you can try is changing thermal_zone polling_frequency to 1 and see whether it change the behavior when you run the workload.

I tried it, but it didn't work. 

Here is what I got from debug messages: 

1.- scaling_max_freq is set to 600000

speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
cpufreq-core: notification 0 of frequency transition to 1400000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
cpufreq-core: notification 1 of frequency transition to 1400000 kHz
cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
printk: 42 messages suppressed.
cpufreq-core: updating policy for CPU 0
cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
cpufreq-core: notification 0 of frequency transition to 600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
cpufreq-core: notification 1 of frequency transition to 600000 kHz
cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 600000 kHz, relation 1
freq-table: request for target 600000 kHz (relation: 1) for cpu 0

2.- I can set 1600000 again and it works

cpufreq-core: updating policy for CPU 0
cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
cpufreq-core: notification 0 of frequency transition to 1600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
cpufreq-core: notification 1 of frequency transition to 1600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 600000 kHz, relation 1
freq-table: request for target 600000 kHz (relation: 1) for cpu 0
freq-table: target is 7 (600000 kHz, 1554)
speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612

I hope it helps to catch the problem. 

> Thanks,
> Venki
> 

Thanks,
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Thomas Renninger]

[-- Attachment #1: Type: text/plain, Size: 7385 bytes --]

On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >  
> Here is what I got from debug messages: 
> 
> 1.- scaling_max_freq is set to 600000
> 
> speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> printk: 42 messages suppressed.
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
BIOS probably reduced freq behind kernel's back (you didn't unplug AC?,
so this machine might also just reduce freq by BIOS for thermal
issues?):
I expect you run through:
 drivers/cpufreq/cpufreq.c:cpufreq_update_policy():
      /* BIOS might change freq behind our back
          -> ask driver for current freq and notify governors about a change */
        if (cpufreq_driver->get) {
                policy.cur = cpufreq_driver->get(cpu);
                if (!data->cur) {
                        dprintk("Driver did not initialize current freq");
                        data->cur = policy.cur;
                } else {
                        if (data->cur != policy.cur)
                                cpufreq_out_of_sync(cpu, data->cur, policy.cur);
                }
        }

> cpufreq-core: notification 0 of frequency transition to 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: notification 1 of frequency transition to 600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> 
> 2.- I can set 1600000 again and it works
> 
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
Looks like BIOS decided that we can use highest freq again and directly
sets the freq to 1600 and kernel didn't notice.
> cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
Oh something went wrong, request should always be from (600000-1600000).
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
Eventually freq could get limited here if BIOS (_PPC) still does not
allow highest freq. But here it would/should allow it again.
It seems as if the "real" max_freq can still be accidently overridden by
the temporary limited max_freq.
I think this could only happen by calling cpufreq_set_policy(..) (or the
one used by min,max sysfs writes), but maybe it may also happen
somewhere else...

> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> freq-table: target is 7 (600000 kHz, 1554)
> speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> 
> I hope it helps to catch the problem. 

If you could tell us what kind of userspace tool you are using to
control cpufreq, that would help a lot.

If this tool still makes use of the deprecated /proc/ interface then
better upgrade this one.

IMO cpufreq_set_policy should not be exported as it is quite dangerous,
doing:

policy.max=xy
cpufreq_set_policy(&policy)

Will override the static max_freq (data->user_policy.max) with the
temporarily limited one (what should only happen if writing to
scaling_max_freq).

Only place I found this call was in drivers/acpi/processor_perflib.c
If your userspace tool sets frequency over that one (what it should not
do):
/proc/acpi/processor/XY/performance
this patch might help, otherwise it will not.

But instead of this patch, I think it's better to rip out this file
totally as it also does not provide SMP capabilities (on an SMP system
writing to it, may randomly modify frequency of one of the CPUs).

Compile tested and patched again 2.6.18-rc4:

 drivers/acpi/processor_perflib.c |    9 +++++----
 drivers/cpufreq/cpufreq.c        |    4 +---
 2 files changed, 6 insertions(+), 7 deletions(-)

Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
+++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
@@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
 	struct acpi_processor *pr = (struct acpi_processor *)m->private;
 	struct acpi_processor_performance *perf;
 	char state_string[12] = { '\0' };
-	unsigned int new_state = 0;
+	unsigned int new_state, new_freq = 0;
 	struct cpufreq_policy policy;
 
 
@@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
 	cpufreq_get_policy(&policy, pr->id);
 
 	policy.cpu = pr->id;
-	policy.min = perf->states[new_state].core_frequency * 1000;
-	policy.max = perf->states[new_state].core_frequency * 1000;
+	new_freq = perf->states[new_state].core_frequency * 1000;
+
+	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
+
 
-	result = cpufreq_set_policy(&policy);
 	if (result)
 		return result;
 
Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1448,7 +1448,7 @@ error_out:
  *
  *	Sets a new CPU frequency and voltage scaling policy.
  */
-int cpufreq_set_policy(struct cpufreq_policy *policy)
+static int cpufreq_set_policy(struct cpufreq_policy *policy)
 {
 	int ret = 0;
 	struct cpufreq_policy *data;
@@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_set_policy);
-
 
 /**
  *	cpufreq_update_policy - re-evaluate an existing cpufreq policy



[-- Attachment #2: cpufreq_dont_override_max_freq.patch --]
[-- Type: text/x-patch, Size: 1832 bytes --]

 drivers/acpi/processor_perflib.c |    9 +++++----
 drivers/cpufreq/cpufreq.c        |    4 +---
 2 files changed, 6 insertions(+), 7 deletions(-)

Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
+++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
@@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
 	struct acpi_processor *pr = (struct acpi_processor *)m->private;
 	struct acpi_processor_performance *perf;
 	char state_string[12] = { '\0' };
-	unsigned int new_state = 0;
+	unsigned int new_state, new_freq = 0;
 	struct cpufreq_policy policy;
 
 
@@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
 	cpufreq_get_policy(&policy, pr->id);
 
 	policy.cpu = pr->id;
-	policy.min = perf->states[new_state].core_frequency * 1000;
-	policy.max = perf->states[new_state].core_frequency * 1000;
+	new_freq = perf->states[new_state].core_frequency * 1000;
+
+	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
+
 
-	result = cpufreq_set_policy(&policy);
 	if (result)
 		return result;
 
Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1448,7 +1448,7 @@ error_out:
  *
  *	Sets a new CPU frequency and voltage scaling policy.
  */
-int cpufreq_set_policy(struct cpufreq_policy *policy)
+static int cpufreq_set_policy(struct cpufreq_policy *policy)
 {
 	int ret = 0;
 	struct cpufreq_policy *data;
@@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_set_policy);
-
 
 /**
  *	cpufreq_update_policy - re-evaluate an existing cpufreq policy

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 8402 bytes --]

El jue, 17-08-2006 a las 12:46 +0200, Thomas Renninger escribió:
> On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> > El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> > >  
> > Here is what I got from debug messages: 
> > 
> > 1.- scaling_max_freq is set to 600000
> > 
> > speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> > cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> > cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> > cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> > printk: 42 messages suppressed.
> > cpufreq-core: updating policy for CPU 0
> > cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
> BIOS probably reduced freq behind kernel's back (you didn't unplug AC?,
> so this machine might also just reduce freq by BIOS for thermal
> issues?):

No, AC is always plugged.

> I expect you run through:
>  drivers/cpufreq/cpufreq.c:cpufreq_update_policy():
>       /* BIOS might change freq behind our back
>           -> ask driver for current freq and notify governors about a change */
>         if (cpufreq_driver->get) {
>                 policy.cur = cpufreq_driver->get(cpu);
>                 if (!data->cur) {
>                         dprintk("Driver did not initialize current freq");
>                         data->cur = policy.cur;
>                 } else {
>                         if (data->cur != policy.cur)
>                                 cpufreq_out_of_sync(cpu, data->cur, policy.cur);
>                 }
>         }
> 
> > cpufreq-core: notification 0 of frequency transition to 600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> > cpufreq-core: notification 1 of frequency transition to 600000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> > cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> > freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> > cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> > cpufreq-core: governor: change or update limits
> > cpufreq-core: __cpufreq_governor for CPU 0, event 3
> > cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> > freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> > 
> > 2.- I can set 1600000 again and it works
> > 
> > cpufreq-core: updating policy for CPU 0
> > cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
> Looks like BIOS decided that we can use highest freq again and directly
> sets the freq to 1600 and kernel didn't notice.
> > cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> > cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> > cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> Oh something went wrong, request should always be from (600000-1600000).
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> Eventually freq could get limited here if BIOS (_PPC) still does not
> allow highest freq. But here it would/should allow it again.
> It seems as if the "real" max_freq can still be accidently overridden by
> the temporary limited max_freq.
> I think this could only happen by calling cpufreq_set_policy(..) (or the
> one used by min,max sysfs writes), but maybe it may also happen
> somewhere else...
> 
> > cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> > cpufreq-core: governor: change or update limits
> > cpufreq-core: __cpufreq_governor for CPU 0, event 3
> > cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> > freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> > freq-table: target is 7 (600000 kHz, 1554)
> > speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> > 
> > I hope it helps to catch the problem. 
> 
> If you could tell us what kind of userspace tool you are using to
> control cpufreq, that would help a lot.

I don't use any tool. I use conservative governor. When scaling_max_freq
is set to 600 I try to set 1600 again directly with echo. I don't use
any other tool to control cpufreq.

> If this tool still makes use of the deprecated /proc/ interface then
> better upgrade this one.

No, it's even not compiled. 

> IMO cpufreq_set_policy should not be exported as it is quite dangerous,
> doing:
> 
> policy.max=xy
> cpufreq_set_policy(&policy)
> 
> Will override the static max_freq (data->user_policy.max) with the
> temporarily limited one (what should only happen if writing to
> scaling_max_freq).
> 
> Only place I found this call was in drivers/acpi/processor_perflib.c
> If your userspace tool sets frequency over that one (what it should not
> do):
> /proc/acpi/processor/XY/performance
> this patch might help, otherwise it will not.
> 
> But instead of this patch, I think it's better to rip out this file
> totally as it also does not provide SMP capabilities (on an SMP system
> writing to it, may randomly modify frequency of one of the CPUs).
> 
> Compile tested and patched again 2.6.18-rc4:
> 
>  drivers/acpi/processor_perflib.c |    9 +++++----
>  drivers/cpufreq/cpufreq.c        |    4 +---
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
> ===================================================================
> --- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
> +++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
> @@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
>  	struct acpi_processor *pr = (struct acpi_processor *)m->private;
>  	struct acpi_processor_performance *perf;
>  	char state_string[12] = { '\0' };
> -	unsigned int new_state = 0;
> +	unsigned int new_state, new_freq = 0;
>  	struct cpufreq_policy policy;
>  
> 
> @@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
>  	cpufreq_get_policy(&policy, pr->id);
>  
>  	policy.cpu = pr->id;
> -	policy.min = perf->states[new_state].core_frequency * 1000;
> -	policy.max = perf->states[new_state].core_frequency * 1000;
> +	new_freq = perf->states[new_state].core_frequency * 1000;
> +
> +	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
> +
>  
> -	result = cpufreq_set_policy(&policy);
>  	if (result)
>  		return result;
>  
> Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
> ===================================================================
> --- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
> +++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
> @@ -1448,7 +1448,7 @@ error_out:
>   *
>   *	Sets a new CPU frequency and voltage scaling policy.
>   */
> -int cpufreq_set_policy(struct cpufreq_policy *policy)
> +static int cpufreq_set_policy(struct cpufreq_policy *policy)
>  {
>  	int ret = 0;
>  	struct cpufreq_policy *data;
> @@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
>  
>  	return ret;
>  }
> -EXPORT_SYMBOL(cpufreq_set_policy);
> -
>  
>  /**
>   *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
> 
> 

Thanks a lot, 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

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

RE: cpufreq stops working after a while

[Thomas Renninger]

On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >  

Sorry, I don't see it... A last guess...
When these Dells allow freqs again after (un-)plugging AC, a processor
event is thrown, _PPC is reread and freqs are allowed again.
This works AFAIK.

Maybe this processor event is missing when the machine unlimits freq
because of thermal issues and _PPC does not get updated.

You should be able to test this by:
If you run into this issue (freq limited), wait a while until the
machine is cool (better wait a bit longer..) then unplug and replug the
AC adapter. Then wait for ten seconds. _PPC should get reevaluated and
max_freq should be set to highest freq again.

You can watch the acpi events by stopping hal/acpid whatever
accesses /proc/acpi/events, then do cat /proc/acpi/events.
Something like:
processor CPU0 0000008X 00000000
allows all freqs again
processor CPU0 0000008X 00000002
e.g. limits frequencies to the third highest.

If this is the case (processor event to allow all freqs again is
missing), the attached patch (patch is on top of the one I posted some
minutes ago) might help.

> 1.- scaling_max_freq is set to 600000
> 
> speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> printk: 42 messages suppressed.
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
> cpufreq-core: notification 0 of frequency transition to 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: notification 1 of frequency transition to 600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> 
> 2.- I can set 1600000 again and it works
> 
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
This is where I expect freqs are allowed again and simply increase
max_freq to current_freq..., it's as ugly as the machine' BIOS ...

> cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> freq-table: target is 7 (600000 kHz, 1554)
> speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> 
> I hope it helps to catch the problem. 

Hope that helps, if not I run out of ideas...

 drivers/cpufreq/cpufreq.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1514,8 +1514,12 @@ int cpufreq_update_policy(unsigned int c
 			dprintk("Driver did not initialize current freq");
 			data->cur = policy.cur;
 		} else {
-			if (data->cur != policy.cur)
+			if (data->cur != policy.cur){
 				cpufreq_out_of_sync(cpu, data->cur, policy.cur);
+				if (data->cur > policy.max)
+					data->user_policy.max = policy.max =
+						data->cur;
+			}
 		}
 	}