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?
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
On Fri, 11 Aug 2006 14:25:26 -0400
Mark Lord <[email protected]> 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 ;)
Andrew Morton wrote:
> Mark Lord <[email protected]> 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
Andrew Morton wrote:
> On Fri, 11 Aug 2006 14:25:26 -0400
> Mark Lord <[email protected]> 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 ?
On Fri, 11 Aug 2006 15:10:16 -0400
Mark Lord <[email protected]> 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.
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.
??
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] 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
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
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
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:~#
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!
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
>-----Original Message-----
>From: Mark Lord [mailto:[email protected]]
>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
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
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?
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
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
>-----Original Message-----
>From: Mark Lord [mailto:[email protected]]
>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
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.
??
>-----Original Message-----
>From: Mark Lord [mailto:[email protected]]
>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
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.
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
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 | [email protected]