F14 cpuspeed / ondemand broken?

[Steven Haigh]

I've been trying to nut out an issue with cpuspeed on a Fedora14 box...

It seems when cpuspeed is started, it clocks the frequency back to the 
lowest available (350Mhz in my case), and there it stays.

If I do something to create CPU load ( while true; do true; done ) then 
the CPU fails to be clocked back up to max frequency. In fact, no matter 
what I do on that box the CPU doesn't move from 350Mhz...

To get the system back to 2.8Ghz I need to rmmod the p4-clockmod module.

I thought this might have been something silly with the thresholds so I 
set UP_THRESHOLD and DOWN_THRESHOLD manually in /etc/sysconfig/cpuspeed 
- however then when starting cpuspeed I see:

# /etc/init.d/cpuspeed restart
Disabling performance cpu frequency scaling:               [  OK  ]
/etc/init.d/cpuspeed: line 86: 
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold: No such file 
or directory
/etc/init.d/cpuspeed: line 86: 
/sys/devices/system/cpu/cpu1/cpufreq/ondemand/up_threshold: No such file 
or directory
Enabling ondemand cpu frequency scaling:                   [  OK  ]

Kernel version is:
# cat /proc/version
Linux version 2.6.35.6-45.fc14.i686 
(mockbuild(a)x86-16.phx2.fedoraproject.org) (gcc version 4.5.1 20100924 
(Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18 23:56:17 UTC 2010

Anyone have any ideas on this? :\

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Steven Haigh]

On 24/12/2010 4:59 PM, Steven Haigh wrote:
>  I've been trying to nut out an issue with cpuspeed on a Fedora14
> box...
>
>  It seems when cpuspeed is started, it clocks the frequency back to the
>  lowest available (350Mhz in my case), and there it stays.
>
>  If I do something to create CPU load ( while true; do true; done ) then
>  the CPU fails to be clocked back up to max frequency. In fact, no matter
>  what I do on that box the CPU doesn't move from 350Mhz...
>
>  To get the system back to 2.8Ghz I need to rmmod the p4-clockmod module.
>
>  I thought this might have been something silly with the thresholds so I
>  set UP_THRESHOLD and DOWN_THRESHOLD manually in /etc/sysconfig/cpuspeed
>  - however then when starting cpuspeed I see:
>
>  # /etc/init.d/cpuspeed restart
>  Disabling performance cpu frequency scaling: [ OK ]
>  /etc/init.d/cpuspeed: line 86:
>  /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold: No such file
>  or directory
>  /etc/init.d/cpuspeed: line 86:
>  /sys/devices/system/cpu/cpu1/cpufreq/ondemand/up_threshold: No such file
>  or directory
>  Enabling ondemand cpu frequency scaling: [ OK ]
>
>  Kernel version is:
>  # cat /proc/version
>  Linux version 2.6.35.6-45.fc14.i686
>  (mockbuild(a)x86-16.phx2.fedoraproject.org) (gcc version 4.5.1 20100924
>  (Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18 23:56:17 UTC 2010
>
>  Anyone have any ideas on this? :\
>  
This gets even more interesting!

# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq(a)vger.kernel.org, please.
analyzing CPU 0:
   driver: p4-clockmod
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency: 10.00 ms.
   hardware limits: 350 MHz - 2.80 GHz
   available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75 
GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
   available cpufreq governors: ondemand, userspace, performance
   current policy: frequency should be within 350 MHz and 2.80 GHz.
                The governor "performance" may decide which speed to use
                within this range.
   current CPU frequency is 2.80 GHz (asserted by call to hardware).
analyzing CPU 1:
   driver: p4-clockmod
   CPUs which run at the same hardware frequency: 1
   CPUs which need to have their frequency coordinated by software: 1
   maximum transition latency: 10.00 ms.
   hardware limits: 350 MHz - 2.80 GHz
   available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75 
GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
   available cpufreq governors: ondemand, userspace, performance
   current policy: frequency should be within 350 MHz and 2.80 GHz.
                The governor "performance" may decide which speed to use
                within this range.
   current CPU frequency is 2.80 GHz (asserted by call to hardware).

Ok, so it thinks its using the performance governor - even though the 
config files for cpuspeed say to use ondemand..

# cpufreq-set -g ondemand
# echo $?
0

Now it should have set ondemand as the governor.

# cpufreq-info | grep governor
   available cpufreq governors: ondemand, userspace, performance
                The governor "performance" may decide which speed to use
   available cpufreq governors: ondemand, userspace, performance
                The governor "performance" may decide which speed to use

Interesting. No change at all.

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Richard Shaw]

On Fri, Dec 24, 2010 at 12:24 AM, Steven Haigh <netwiz(a)crc.id.au&gt; wrote:
>  On 24/12/2010 4:59 PM, Steven Haigh wrote:
> > I've been trying to nut out an issue with cpuspeed on a Fedora14 box...
> >
> > It seems when cpuspeed is started, it clocks the frequency back to the
> > lowest available (350Mhz in my case), and there it stays.
> >
> > If I do something to create CPU load ( while true; do true; done ) then
> > the CPU fails to be clocked back up to max frequency. In fact, no matter
> > what I do on that box the CPU doesn't move from 350Mhz...
> >
> > To get the system back to 2.8Ghz I need to rmmod the p4-clockmod module.
> >
> > I thought this might have been something silly with the thresholds so I
> > set UP_THRESHOLD and DOWN_THRESHOLD manually in /etc/sysconfig/cpuspeed
> > - however then when starting cpuspeed I see:
> >
> > # /etc/init.d/cpuspeed restart
> > Disabling performance cpu frequency scaling: [ OK ]
> > /etc/init.d/cpuspeed: line 86:
> > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold: No such file
> > or directory
> > /etc/init.d/cpuspeed: line 86:
> > /sys/devices/system/cpu/cpu1/cpufreq/ondemand/up_threshold: No such file
> > or directory
> > Enabling ondemand cpu frequency scaling: [ OK ]
> >
> > Kernel version is:
> > # cat /proc/version
> > Linux version 2.6.35.6-45.fc14.i686
> > (mockbuild(a)x86-16.phx2.fedoraproject.org) (gcc version 4.5.1 20100924
> > (Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18 23:56:17 UTC 2010
> >
> > Anyone have any ideas on this? :\
> >
>
>  This gets even more interesting!
>
>  # cpufreq-info
>  cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
>  Report errors and bugs to cpufreq(a)vger.kernel.org, please.
>  analyzing CPU 0:
>    driver: p4-clockmod
>    CPUs which run at the same hardware frequency: 0
>    CPUs which need to have their frequency coordinated by software: 0
>    maximum transition latency: 10.00 ms.
>    hardware limits: 350 MHz - 2.80 GHz
>    available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75
>  GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
>    available cpufreq governors: ondemand, userspace, performance
>    current policy: frequency should be within 350 MHz and 2.80 GHz.
>                 The governor "performance" may decide which speed to use
>                 within this range.
>    current CPU frequency is 2.80 GHz (asserted by call to hardware).
>  analyzing CPU 1:
>    driver: p4-clockmod
>    CPUs which run at the same hardware frequency: 1
>    CPUs which need to have their frequency coordinated by software: 1
>    maximum transition latency: 10.00 ms.
>    hardware limits: 350 MHz - 2.80 GHz
>    available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75
>  GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
>    available cpufreq governors: ondemand, userspace, performance
>    current policy: frequency should be within 350 MHz and 2.80 GHz.
>                 The governor "performance" may decide which speed to use
>                 within this range.
>    current CPU frequency is 2.80 GHz (asserted by call to hardware).
>
>  Ok, so it thinks its using the performance governor - even though the
>  config files for cpuspeed say to use ondemand..
>
>  # cpufreq-set -g ondemand
>  # echo $?
>  0
>
>  Now it should have set ondemand as the governor.
>
>  # cpufreq-info | grep governor
>    available cpufreq governors: ondemand, userspace, performance
>                 The governor "performance" may decide which speed to use
>    available cpufreq governors: ondemand, userspace, performance
>                 The governor "performance" may decide which speed to use
>
>  Interesting. No change at all. 
I wish I could find the site where I got this information as my
recollection of it is a bit hazy but part of your problem may be that
the p4-clockmod and ondemand are more or less incompatible. I remember
reading something on kerneltrap or something. Basically the latency of
changing frequencies are so bad with p4-clockmod that ondemand gives
up on it or something like that. I think I could force it to work on
my Celeron based EEEPC by manually setting the governor something like
this[1]:

---
Using Frequency Scaling Governors

You can get a list of available governors with (as root):
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative ondemand powersave userspace performance

Note: If the governors are compiled as modules, load them first:
# modprobe cpufreq_performance cpufreq_ondemand cpufreq_conservative
cpufreq_powersave cpufreq_userspace

Now we set our governor: What is our current governor?
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
userspace

Set new governor and watch if it has changed
# echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
conservative

Congrats! Your governor is active.
You may set the governor in your rc.local, to make it used on every boot.
---

Richard

[1] http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling

[Steven Haigh]

On 1/01/2011 1:49 AM, Richard Shaw wrote:
>  I wish I could find the site where I got this information as my
>  recollection of it is a bit hazy but part of your problem may be that
>  the p4-clockmod and ondemand are more or less incompatible. I remember
>  reading something on kerneltrap or something. Basically the latency of
>  changing frequencies are so bad with p4-clockmod that ondemand gives
>  up on it or something like that. I think I could force it to work on
>  my Celeron based EEEPC by manually setting the governor something like
>  this[1]:
>
>  ---
>  Using Frequency Scaling Governors
>
>  You can get a list of available governors with (as root):
>  # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
>  conservative ondemand powersave userspace performance
>
>  Note: If the governors are compiled as modules, load them first:
>  # modprobe cpufreq_performance cpufreq_ondemand cpufreq_conservative
>  cpufreq_powersave cpufreq_userspace
>
>  Now we set our governor: What is our current governor?
>  # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>  userspace
>
>  Set new governor and watch if it has changed
>  # echo conservative>  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>  # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
>  conservative
>
>  Congrats! Your governor is active.
>  You may set the governor in your rc.local, to make it used on every boot.
>  ---
>
>  Richard
>
>  [1] http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling 
Interestingly enough, I tried setting the governor to userspace. Now 
when I run /etc/init.d/cpuspeed start, I can see the CPU speed scale. It 
isn't as quick as the kernel ondemand governor, but it does scale up and 
down with load.

This makes me quite curious.

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Christoph Frieben]

You might want to have a look at bug reports

    https://bugzilla.redhat.com/show_bug.cgi?id=505837
    https://bugzilla.redhat.com/show_bug.cgi?id=518377

which dealt with this issue some time ago. Module p4-clockmod does not
provide a true frequency scaling as available on systems which support
SpeedStep. It is basically considered useless and even has
disadvantages such as increasing system latency,

    http://lkml.org/lkml/2006/2/25/84 .

Modern Intel CPUs will rather use the SpeedStep driver. ~C

[Adam Williamson]

On Fri, 2010-12-31 at 08:49 -0600, Richard Shaw wrote:

>  I wish I could find the site where I got this information as my
>  recollection of it is a bit hazy but part of your problem may be that
>  the p4-clockmod and ondemand are more or less incompatible. I remember
>  reading something on kerneltrap or something. Basically the latency of
>  changing frequencies are so bad with p4-clockmod that ondemand gives
>  up on it or something like that. I think I could force it to work on
>  my Celeron based EEEPC by manually setting the governor something like
>  this[1]: 
yeah, I recall p4-clockmod being called out as problematic in several
ways by some kernel dev or other, but like you I can't recall the
details :/

on my system which wants to use p4-clockmod, I just blacklist it and run
full steam ahead all the time.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[drago01]

On Mon, Jan 3, 2011 at 2:08 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Fri, 2010-12-31 at 08:49 -0600, Richard Shaw wrote:
>
> > I wish I could find the site where I got this information as my
> > recollection of it is a bit hazy but part of your problem may be that
> > the p4-clockmod and ondemand are more or less incompatible. I remember
> > reading something on kerneltrap or something. Basically the latency of
> > changing frequencies are so bad with p4-clockmod that ondemand gives
> > up on it or something like that. I think I could force it to work on
> > my Celeron based EEEPC by manually setting the governor something like
> > this[1]:
>
>  yeah, I recall p4-clockmod being called out as problematic in several
>  ways by some kernel dev or other, but like you I can't recall the
>  details :/
>
>  on my system which wants to use p4-clockmod, I just blacklist it and run
>  full steam ahead all the time. 
And uses _less_ power while doing so.

See: http://codemonkey.org.uk/2009/01/18/forthcoming-p4clockmod/

In short p4-clockmode is broken by design, don't use it.

[Steven Haigh]

On 4/01/2011 12:08 AM, Adam Williamson wrote:
>  On Fri, 2010-12-31 at 08:49 -0600, Richard Shaw wrote:
>
> > I wish I could find the site where I got this information as my
> > recollection of it is a bit hazy but part of your problem may be that
> > the p4-clockmod and ondemand are more or less incompatible. I remember
> > reading something on kerneltrap or something. Basically the latency of
> > changing frequencies are so bad with p4-clockmod that ondemand gives
> > up on it or something like that. I think I could force it to work on
> > my Celeron based EEEPC by manually setting the governor something like
> > this[1]:
>
>  yeah, I recall p4-clockmod being called out as problematic in several
>  ways by some kernel dev or other, but like you I can't recall the
>  details :/
>
>  on my system which wants to use p4-clockmod, I just blacklist it and run
>  full steam ahead all the time. 
What I don't understand is that if the CPU supports ACPI, the mainboard 
supports ACPI, why can't we throttle the CPU using ACPI?

 From /proc/cpuinfo:
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm 
constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Steven Haigh]

On 4/01/2011 12:29 AM, Steven Haigh wrote:
>  On 4/01/2011 12:08 AM, Adam Williamson wrote:
> > On Fri, 2010-12-31 at 08:49 -0600, Richard Shaw wrote:
> >
> >> I wish I could find the site where I got this information as my
> >> recollection of it is a bit hazy but part of your problem may be that
> >> the p4-clockmod and ondemand are more or less incompatible. I remember
> >> reading something on kerneltrap or something. Basically the latency of
> >> changing frequencies are so bad with p4-clockmod that ondemand gives
> >> up on it or something like that. I think I could force it to work on
> >> my Celeron based EEEPC by manually setting the governor something like
> >> this[1]:
> >
> > yeah, I recall p4-clockmod being called out as problematic in several
> > ways by some kernel dev or other, but like you I can't recall the
> > details :/
> >
> > on my system which wants to use p4-clockmod, I just blacklist it and run
> > full steam ahead all the time.
>
>  What I don't understand is that if the CPU supports ACPI, the mainboard
>  supports ACPI, why can't we throttle the CPU using ACPI?
>
>    From /proc/cpuinfo:
>  flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>  cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
>  constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm
>  
I think I may have answered my own question:

http://ark.intel.com/Product.aspx?id=27512&processor=820&spec-cod...

 From this, it states the CPU doesn't support Enhanced SpeedStep or 
Demand Based Switching - both of which I assume is what acpi-cpufreq 
uses to reduce power usage on the CPUs which support these features.

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Jóhann B. Guðmundsson]

On 01/03/2011 01:29 PM, Steven Haigh wrote:
>  What I don't understand is that if the CPU supports ACPI, the
> mainboard
>  supports ACPI, why can't we throttle the CPU using ACPI? 
As I have mentioned several most likely cause is the BIOS either not 
configured to do so or unable to do so..

INTEL has some processors that report they can while en fact they cant.

To find that out you would have to dig deep into Intel docs.

Look for the Highest Frequency Mode (HFM) and Lowest Frequency Mode 
(LFM) in those documents for your processors and if it says that the 
processor in question operates at same core frequency in HFM and LFM 
then it cant but I dont think you need to worry about that since you 
mentioned that it did switch cpufrequency when run with GOVERNOR=userspace.

JBG

[Jóhann B. Guðmundsson]

On 12/24/2010 05:59 AM, Steven Haigh wrote:
>  Anyone have any ideas on this? :\ 
BIOS/platform issueis a common cause for the problem you are describing.

First is to see what scaling frequency are offered and you can do so by 
running...

"cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies"

Next is to check what bios_limit the kernel sees and you can do so by 
running...

"cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit".

If "bios limit" reports the highest available scaling frequency while 
running plugged in and the lowest available scaling frequency when 
unplugged as in running on battery it is not the culprit.

Just run "watch -n1 "cat 
/sys/devices/system/cpu/cpu*/cpufreq/bios_limit"" and plug/unplug/plug 
on your laptop and the frequency should change from highest to lowest to 
highest again.

If it does not change frequency on battery or on AC or at specific temp 
or with a specific AC adapteryou need to upgraded your bios to the 
latest for your manufacturer and search for SpeedStep, CPU frequency, 
P-state or power management related options ( often there are some knobs 
there that need to be set to "performance" ) in the bios and try 
changing it.

If turning all the bios knobs from "power save" or similar to 
"performance" or similar does not change the bios_limit you can override 
it by adding "processor.ignore_ppc=1" to the kernel line in grub or run 
"echo 1 > /sys/module/processor/parameters/ignore_ppc" to tweak it 
during runtime however be aware that there must be a reason why the 
vendor/OEM is limiting your frequency in the first place.

If "bios_limit" is not the cause for this start by trying the latest 
kernel versions for .35 .36 and .37 in koji and see if it's fixed in any 
of them if not you will need to file a bug report and make sure the 
kernel is compiled with CPU_FREQ_DEBUG=y and you boot with 
"cpufreq.debug=7" or run "echo 7 > 
/sys/module/cpufreq/parameters/debug"to tweak it during runtime and then 
attach "dmesg > dmesg.txt"  along with the output from "for x in 
/sys/devices/system/cpu/cpu0/cpufreq/*;do echo $x;cat $x;done && for x 
in /sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat 
$x;done" to your report which should provide the maintainer with 
sufficient info to start working on your report.

Also take a look at various commands that come with the cpufrequtils 
package like cpufreq-info etc..

JBG

[JB]

Jóhann B. Guðmundsson <johannbg <at> gmail.com> writes:

>  ... 
We have here on fedora general (users) a similar case.
I have a very similar machine (Intel dual core) to the guy in trouble, and
I can not fix it for him.
My machine works as expected.

You may take a look if interested:
http://article.gmane.org/gmane.linux.redhat.fedora.general/385448

JB

[Steven Haigh]

Sorry - I think I dropped the ball on this.... Comments inline...

On 27/12/2010 12:50 AM, "Jóhann B. Guðmundsson" wrote:
>  On 12/24/2010 05:59 AM, Steven Haigh wrote:
> > Anyone have any ideas on this? :\
>
>  BIOS/platform issueis a common cause for the problem you are describing.
>
>  First is to see what scaling frequency are offered and you can do so by
>  running...
>
>  "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies"
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
350000 700000 1050000 1400000 1750000 2100000 2450000 2800000

This looks good. From 350Mhz to 2.8Ghz.

>  Next is to check what bios_limit the kernel sees and you can do so
> by
>  running...
>
>  "cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit". 
# cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
cat: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit: No such file or 
directory

>  If "bios limit" reports the highest available scaling
> frequency while
>  running plugged in and the lowest available scaling frequency when
>  unplugged as in running on battery it is not the culprit.
>
>  Just run "watch -n1 "cat
>  /sys/devices/system/cpu/cpu*/cpufreq/bios_limit"" and plug/unplug/plug
>  on your laptop and the frequency should change from highest to lowest to
>  highest again. 
This is a desktop machine - I can't easily unplug it ;)

>  If it does not change frequency on battery or on AC or at specific
> temp
>  or with a specific AC adapter you need to upgraded your bios to the
>  latest for your manufacturer and search for SpeedStep, CPU frequency,
>  P-state or power management related options ( often there are some knobs
>  there that need to be set to "performance" ) in the bios and try
>  changing it. 
I might take a look at this... From memory it's an ASUS mainboard from a 
system that they produce switched into a rackmount case...

>  If turning all the bios knobs from "power save" or similar
> to
>  "performance" or similar does not change the bios_limit you can override
>  it by adding "processor.ignore_ppc=1" to the kernel line in grub or run
>  "echo 1 > /sys/module/processor/parameters/ignore_ppc" to tweak it
>  during runtime however be aware that there must be a reason why the
>  vendor/OEM is limiting your frequency in the first place. 
I should clarify this as I may not have explained it correctly. 
Monitoring the frequency in /proc/cpuinfo, I can see that without 
cpuspeed started, I am at 2.8Ghz. This is expected.

When I start cpuspeed, the CPU drops to 350Mhz. Again, what we expected.

The bad thing is that the CPU never comes out of running at 350Mhz under 
load. The CPU will stay at 350Mhz until the modules are removed via rmmod.

>  If "bios_limit" is not the cause for this start by trying
> the latest
>  kernel versions for .35 .36 and .37 in koji and see if it's fixed in any
>  of them if not you will need to file a bug report and make sure the
>  kernel is compiled with CPU_FREQ_DEBUG=y and you boot with
>  "cpufreq.debug=7" or run "echo 7 >
>  /sys/module/cpufreq/parameters/debug" to tweak it during runtime and then
>  attach "dmesg > dmesg.txt" along with the output from "for x in
>  /sys/devices/system/cpu/cpu0/cpufreq/*;do echo $x;cat $x;done && for x
>  in /sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat
>  $x;done" to your report which should provide the maintainer with
>  sufficient info to start working on your report.
>
>  Also take a look at various commands that come with the cpufrequtils
>  package like cpufreq-info etc.. 
# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq(a)vger.kernel.org, please.
analyzing CPU 0:
   driver: p4-clockmod
   CPUs which run at the same hardware frequency: 0
   CPUs which need to have their frequency coordinated by software: 0
   maximum transition latency: 10.00 ms.
   hardware limits: 350 MHz - 2.80 GHz
   available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75 
GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
   available cpufreq governors: ondemand, userspace, performance
   current policy: frequency should be within 350 MHz and 350 MHz.
                   The governor "performance" may decide which speed to use
                   within this range.
   current CPU frequency is 350 MHz (asserted by call to hardware).
analyzing CPU 1:
   driver: p4-clockmod
   CPUs which run at the same hardware frequency: 1
   CPUs which need to have their frequency coordinated by software: 1
   maximum transition latency: 10.00 ms.
   hardware limits: 350 MHz - 2.80 GHz
   available frequency steps: 350 MHz, 700 MHz, 1.05 GHz, 1.40 GHz, 1.75 
GHz, 2.10 GHz, 2.45 GHz, 2.80 GHz
   available cpufreq governors: ondemand, userspace, performance
   current policy: frequency should be within 350 MHz and 350 MHz.
                   The governor "performance" may decide which speed to use
                   within this range.
   current CPU frequency is 350 MHz (asserted by call to hardware).

Note that cpufreq-info says that it is using the performance governor - 
however in /etc/sysconfig/cpuspeed, I have governor=ondemand.

Extract from /etc/sysconfig/cpuspeed:
DRIVER=p4-clockmod
GOVERNOR=ondemand
MAX_SPEED=
MIN_SPEED=
UP_THRESHOLD=
DOWN_THRESHOLD=
IGNORE_NICE=0

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Jóhann B. Guðmundsson]

<snip>
...
</snip>

1. update bios to the latest from manufacturer and check bios settings ( 
Must do )
2. restore /etc/sysconfig/cpuspeed to it's original form ( Must as well )

Check if things work if they dont after bios update and orignal cpuspeed 
file and after fiddling with power savings, EIST, processor scaling, 
etc.  then boot with cpufreq.debug=7 and test latest kernel .35 .36 .37 
from koji

JBG

[Steven Haigh]

On 31/12/2010 10:16 PM, "Jóhann B. Guðmundsson" wrote:
>  1. update bios to the latest from manufacturer and check bios settings (
>  Must do ) 
Ok. I jumped on the Acer web site... The system is an APSK50 desktop. I 
noticed the BIOS was from 2006 - the latest is R01-C1. I flashed that 
using 'flashrom' which I found to be a lifesaver! I didn't have to get a 
bootable DOS USB key etc! :D

 From dmidecode:
BIOS Information
         Vendor: Phoenix Technologies, LTD
         Version: R01-C1
         Release Date: 05/30/2007
	<snip>
Handle 0x0001, DMI type 1, 27 bytes
System Information
         Manufacturer: Acer
         Product Name: AST690/APFH/APSK50
         Version: R01-C1
         Serial Number:
         UUID: FEFEFEFE-FEFE-FEFE-FEFE-FEFEFEFEFEFE
         Wake-up Type: Power Switch
         SKU Number:
         Family:

The CPU is a socket 775 PentiumD 2.8Ghz.

I reset the BIOS to optimal defaults and fired it up. No real change :(

>  2. restore /etc/sysconfig/cpuspeed to it's original form ( Must
> as well ) 
Did this before I rebooted. If I don't have DRIVER=p4-clockmod set in 
/etc/sysconfig/cpuspeed, when I start it I get a prompt saying that its 
started the ondemand passive cooling. I assume that this means zero 
frequency scaling.

This is a curious thing - when doing this manually:

# /etc/init.d/cpuspeed start
Enabling p4-clockmod driver (passive cooling only):        [  OK  ]

So, unloading all modules and playing manually:
# modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq 
(/lib/modules/2.6.35.10-74.fc14.i686/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko):

No such device

So we can't use acpi. drat. Load p4-clockmod:
# modprobe p4-clockmod

Then lets do some tests.
# pwd
/sys/devices/system/cpu/cpu0/cpufreq
# cat scaling_available_governors
userspace performance
# modprobe cpufreq-ondemand
# cat scaling_available_governors
ondemand userspace performance
# cat scaling_governor
performance
# echo ondemand > scaling_governor
# cat scaling_governor
performance
#

Interesting. Surely this should change to the ondemand governor?!

>  Check if things work if they dont after bios update and orignal
> cpuspeed
>  file and after fiddling with power savings, EIST, processor scaling,
>  etc.then boot with cpufreq.debug=7 and test latest kernel .35 .36 .37
>  from koji 
Going to look into this tomorrow. It's 3:33am now on 1/Jan/2011 - so 
Happy New Year to all, and lets continue the awesome achievements shown 
in Fedora :)

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Jóhann B. Guðmundsson]

On 12/31/2010 04:33 PM, Steven Haigh wrote:
>  I reset the BIOS to optimal defaults and fired it up. No real change
> :(
>  
As I mention you might need to turn some knobs in the bios to get this 
working so using the optimal defaults might be causing this ;)

>  # modprobe acpi-cpufreq
>  FATAL: Error inserting acpi_cpufreq
>
> (/lib/modules/2.6.35.10-74.fc14.i686/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko):
>  No such device
>  
File a bug against the kernel any modern Intel CPU should be driven with 
acpi-cpufreq, the reason I asked you to clean out your config is because 
you should not be using "p4-clockmod".

And to hopefully clear up general internet misconception amongst users 
p4-clockmod is a thermal regulation mechanism it is not a speed control 
or power management mechanism the driver does not scale frequency et al 
the only thing it does is thermal throttling.

Why it still exist still beats me p4-clockmod reports are utterly bogus 
they always have been and using it usually result in the computer being 
slower and consuming more power which nobody wants....

>  Interesting. Surely this should change to the ondemand governor?!
>  
Nope it shouldn't be using any governor which should equal to be using 
the performance governor.

The clockmod code should only be throttling when ACPI indicates that the 
system needs it due to a thermal event.

The only thing you can do since you cant use ondemand is set the cpufreq 
governor to userspace which allows the user, or any userspace 
program running with UID "root", to set the CPU to a specific frequency 
by making a sysfs file "scaling_setspeed" available in the CPU-device 
directory.

> > Check if things work if they dont after bios update and orignal
> cpuspeed
> > file and after fiddling with power savings, EIST, processor scaling,
> > etc.then boot with cpufreq.debug=7 and test latest kernel .35 .36 .37
> > from koji
>  Going to look into this tomorrow. 
Great :)

Try the .36 and .37 kernel to see if acpi_cpufreq module loads in those 
kernels then boot with cpufreq.debug=7  and run dmesg > dmesg.txt then 
file a bug report against the kernel attache dmesg.txt along with the 
output from "for x in /sys/devices/system/cpu/cpu0/cpufreq/*;do echo 
$x;cat $x;done && for x in 
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat $x;done" 
to your report and make note if .36 and .36 work or not

That should provide the maintainer with sufficient info to start working 
on your report.

>  It's 3:33am now on 1/Jan/2011 - so
>  Happy New Year to all, and lets continue the awesome achievements shown
>  in Fedora : 
Happy new year!
( still ca three and an half hour to go here on top of the world ) ;)

JBG

[Steven Haigh]

On 1/01/2011 5:25 AM, "Jóhann B. Guðmundsson" wrote:
>  On 12/31/2010 04:33 PM, Steven Haigh wrote:
> > I reset the BIOS to optimal defaults and fired it up. No real change :(
> >
>
>  As I mention you might need to turn some knobs in the bios to get this
>  working so using the optimal defaults might be causing this ;) 
To be honest, I looked through all the screens of the BIOS and I can't 
see anything that may affect this. As the ONLY defaults option available 
is optimal, I gave it a go ;)

> > # modprobe acpi-cpufreq
> > FATAL: Error inserting acpi_cpufreq
> >
> (/lib/modules/2.6.35.10-74.fc14.i686/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko):
> > No such device
> >
>
>  File a bug against the kernel any modern Intel CPU should be driven with
>  acpi-cpufreq, the reason I asked you to clean out your config is because
>  you should not be using "p4-clockmod". 
Hmm - I updated to kernel 2.6.37-0.rc7.git0.2.fc15.i686 from koji. Seems 
the same issue happens. More on this later.

>  And to hopefully clear up general internet misconception amongst
> users
>  p4-clockmod is a thermal regulation mechanism it is not a speed control
>  or power management mechanism the driver does not scale frequency et al
>  the only thing it does is thermal throttling.
>
>  Why it still exist still beats me p4-clockmod reports are utterly bogus
>  they always have been and using it usually result in the computer being
>  slower and consuming more power which nobody wants.... 
Yeah - the main aim on this is to reduce power consumption - as this 
system is idle for 99.9% of the day :)

> > Interesting. Surely this should change to the ondemand
> governor?!
> >
>
>  Nope it shouldn't be using any governor which should equal to be using
>  the performance governor. 
Ah, that makes sense.

>  The clockmod code should only be throttling when ACPI indicates that
> the
>  system needs it due to a thermal event.
>
>  The only thing you can do since you cant use ondemand is set the cpufreq
>  governor to userspace which allows the user, or any userspace program
>  running with UID "root", to set the CPU to a specific frequency by
>  making a sysfs file "scaling_setspeed" available in the CPU-device
>  directory. 
I believe this is what the cpuspeed process does. It works (as in the 
CPU frequency changes), but isn't exactly optimal :)

> >> Check if things work if they dont after bios update and
> orignal cpuspeed
> >> file and after fiddling with power savings, EIST, processor scaling,
> >> etc.then boot with cpufreq.debug=7 and test latest kernel .35 .36 .37
> >> from koji
> > Going to look into this tomorrow.
>
>  Great :)
>
>  Try the .36 and .37 kernel to see if acpi_cpufreq module loads in those
>  kernels then boot with cpufreq.debug=7 and run dmesg > dmesg.txt then
>  file a bug report against the kernel attache dmesg.txt along with the
>  output from "for x in /sys/devices/system/cpu/cpu0/cpufreq/*;do echo
>  $x;cat $x;done && for x in
>  /sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat $x;done"
>  to your report and make note if .36 and .36 work or not
>
>  That should provide the maintainer with sufficient info to start working
>  on your report.
>  
As noted above, I installed kernel

This bit seems interesting in the dmesg output with cpufreq.debug=7 set:
[    0.655600] speedstep-lib: x86: f, model: 4
[    0.655605] speedstep-ich: Intel(R) SpeedStep(TM) capable processor 
not found
[    0.655609] speedstep-lib: x86: f, model: 4
[    0.655612] speedstep-smi: No supported Intel CPU detected.
[    0.655934] apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
[    0.655938] apm: disabled - APM is not SMP safe.

Early in the boot, the CPU is detected as:
[    0.025581] CPU0: Intel(R) Pentium(R) D CPU 2.80GHz stepping 07

I also note this:
[    0.675591] ACPI: acpi_idle registered with cpuidle
...
[    1.345624] cpuidle: using governor ladder
[    1.345628] cpuidle: using governor menu

This seems to be the part we're interested in however:
[   17.682969] acpi-cpufreq: acpi_cpufreq_init
[   17.682975] acpi-cpufreq: acpi_cpufreq_early_init
[   17.682992] cpufreq-core: trying to register driver acpi-cpufreq
[   17.683020] cpufreq-core: adding CPU 0
[   17.683029] acpi-cpufreq: acpi_cpufreq_cpu_init
[   17.683037] cpufreq-core: initialization failed
[   17.683043] cpufreq-core: adding CPU 1
[   17.683049] acpi-cpufreq: acpi_cpufreq_cpu_init
[   17.683055] cpufreq-core: initialization failed
[   17.683061] cpufreq-core: no CPU initialized for driver acpi-cpufreq
[   17.683067] cpufreq-core: unregistering CPU 0
[   17.683072] cpufreq-core: unregistering CPU 1
[   17.691474] cpufreq-core: trying to register driver p4-clockmod
[   17.691481] cpufreq-core: adding CPU 0

I've logged a bug report on it, I'll add the rest soon.

https://bugzilla.redhat.com/show_bug.cgi?id=666649

-- 
Steven Haigh

Email: netwiz(a)crc.id.au
Web: http://www.crc.id.au
Phone: [phone]
Fax: [phone]

[Jóhann B. Guðmundsson]

On 01/01/2011 09:43 PM, Steven Haigh wrote:
>  To be honest, I looked through all the screens of the BIOS and I
> can't
>  see anything that may affect this. As the ONLY defaults option available
>  is optimal, I gave it a go;) 
Unfortunately it might not be that obvious which BIOS knob(s) need to be 
turned. . . .

As an example in some ASUS BIOS they have a "AITweak section" which has 
an option called  "ASUS/3rdParty UI Priority" which needs to be set to 
"3rdParty" for acpi-cpufreq to load and cpuspeed governors to work 
accordingly.

As you can see in that example it's far from being "Captain Obvious" 
which knob the end user should/needs to turn so users are forced to walk 
the lengthy process of turning a BIOS knob reboot, check, reboot turn 
the next BIOS knob etc.. until they hit the *magic* BIOS knob that turns 
that on.

As I have previously mentioned before, the most common cause these days 
for cpufreq scaling not working is that the BIOS has some secret knob 
that needs to be turned on to do so.

I took a look at your report and noticed that you mentioned that 
"Scaling only happens with DRIVER=p4-clockmod & GOVERNOR=userspace and 
the cpuspeed daemon running." Now once more try to get the wide spread 
ignorance out of your head that p4-clockmod has anything to do with 
frequency scaling. If maintainers sees p4-clockmod on a report against 
component I'm pretty sure that he will direct that report straight to 
/dev/null since their patience in educating reporters if exist in the 
first place is very thin.

The reason the scaling is happening there is because you set the 
governor to userspace so set the DRIVER= and GOVERNOR=userspace and you 
should get the same result as I have previously mentioned and make note 
of that on your bug report.

Now under normal circumstances Matthew Garret or some other kernel 
maintainer would have asked you to add to your report, the output from 
acpidump but given that this has been incorrectly triaged and marked as 
a duplicated of bug 50837 which was filed against F11 our kernel 
maintainers probably wont take a look at it.

I would have expected the kernel team to have opted themselves out of 
triage process or at least be extremly selective on the individuals 
triaging the kernel since it requires a bit more skill set than running 
around changing bug status-is and copy/paste predefined responses to the 
report but since it's not the case, I'm forced to direct you directly 
upstream to the kernel bugzilla ( https://bugzilla.kernel.org/ ) which 
is something usually dont recommend since our bugzilla should be 
sufficient for our reporters and it requires reporters to be educated in 
the art of kernel patching and compiling since upstream oftern request 
reporters to recompile with patch and provide feedback back.

If I noticed more incorrectly triaged reports against the kernel I will 
recommend that we take up the policy of directing our reporters directly 
upstream instead of using our own bugzilla ( it kinda beats the triage 
purpose if maintainers are forced to oversee the triage process 
themselves ) anyway creating bugzilla account on bugzilla.kernel.org is 
a breeze and should take you a less then a minute to setup simply click 
"Open a new Kernel Bug Tracker account"
type in your email address and confirm and provide your real name and 
password and you are good to go.

Login into your newly created account and click New, click "Power 
Management" in "Component" select cpufreq in "Kernel Version:"
put the 
kernel versions you tested this on, in "Tree" select Fedora, in summary 
put something like cpufreq does not work on <insert cpu type>/<insert 
platform>, In Description you should simply put. Summary says it all and 
make note if you have tried turning some bios knobs and it did not make 
a difference.

Then restore "/etc/sysconfig/cpuspeed" to it's original form, install 
the pmtools package which contains acpidump and boot with "cpufreq.debug=7".

Run. . .

dmidecode > /tmp/dmidecode.txt and attach it to the report
dmesg > /tmp/dmesg.txt and attach it to the report
acpidump > /tmp/acpidump.txt and attach it to the report
And the output of "for x in /sys/devices/system/cpu/cpu0/cpufreq/*;do 
echo $x;cat $x;done && for x in 
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat $x;done" 
in a file that's attached to the bug report.

JBG

[Christoph Frieben]

2011/1/3 "Jóhann B. Guðmundsson":
>  Now under normal circumstances Matthew Garret or some other kernel
>  maintainer would have asked you to add to your report, the output from
>  acpidump but given that this has been incorrectly triaged and marked as a
>  duplicated of bug 50837 which was filed against F11 our kernel maintainers
>  probably wont take a look at it.
>
>  I would have expected the kernel team to have opted themselves out of triage
>  process or at least be extremly selective on the individuals triaging the
>  kernel since it requires a bit more skill set than running around changing
>  bug status-is and copy/paste predefined responses to the report but since
>  it's not the case, I'm forced to direct you directly upstream to the kernel
>  bugzilla ( https://bugzilla.kernel.org/ ) which is something usually dont
>  recommend since our bugzilla should be sufficient for our reporters and it
>  requires reporters to be educated in the art of kernel patching and
>  compiling since upstream oftern request reporters to recompile with patch
>  and provide feedback back. 
Bug 666649 has not been marked a duplicate of whatsoever. Moreover
it's active since its status is "NEW" and not "CLOSED". ~C

[Jóhann B. Guðmundsson]

On 01/03/2011 02:36 PM, Christoph Frieben wrote:
>  Bug 666649 has not been marked a duplicate of whatsoever. Moreover
>  it's active since its status is "NEW" and not "CLOSED". ~C
Comment 3

<mailto:[e-mail]>*** Duplicate of bug 505837 
<https://bugzilla.redhat.com/show_bug.cgi?id=505837> ***

Which has "Status: CLOSED ERRATA"

JBG