Wrong CPU scaling frequencies

[Arnold J Noronha]

Binary package hint: powernowd

I did an apt upgrade today on my feisty laptop (HP nx6110), my CPU's scaling frequencies are displayed wrongly - or at least differently from my earlier ubuntu's and other installations. Usually my lowest frequency is 800 MHz, now its 798 MHz. My scaling_avalable_frequencies now shows:

798000 1064000 1330000 1729000

The first one used to be 800000, and the last one used to be 1733000. I don't remember the intermediate values for sure.

Kernel: 2.6.20-13-386

lshw output for my CPU:
  *-cpu
          description: CPU
          product: Intel(R) Pentium(R) M processor 1.73GHz
          vendor: Intel Corp.
          physical id: 4
          bus info: cpu@0
          version: 6.13.8
          slot: JP12
          size: 1729MHz
          capacity: 1733MHz
          width: 32 bits
          clock: 133MHz
          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic
 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est t
m2 cpufreq

Just in case it helps, along with this I'm also experiencing a possible (though not exact) instance of bug #92014, my IDE drives have now become /dev/sda*.

Btw, I'm not experiencing any troubles due to this, but would this be damaging to the CPU?

[Cesare Tirabassi (norsetto)]

This might not be powernowd. What is the active governor?

[Arnold J Noronha (arnold)]

On Wed, Mar 28, 2007 at 07:06:36PM -0000, Cesare Tirabassi wrote:
> This might not be powernowd. What is the active governor?

ondemand

--Arnold

[Cesare Tirabassi (norsetto)]

Than it's not powernowd.
I think it would be helpful to have a look at your dmesg and syslog.
Can you also tell us what modules are loaded (lsmod) as well as give us the output of a cat command of all the files in /sys/devices/system/cpu/cpu0/cpufreq?
An lspci -vv and lspci -vvn output can also be helpful.

[Arnold J Noronha (arnold)]

Ok, so I've attached what you asked for.

[Cesare Tirabassi (norsetto)]

Thanks for your cooperation Arnold.
Please next time it would be better to not tar or compress attachments.

From a first glance, only thing that looks strange is concerning the speedstep_centrino module. I understand it is deprecated and most of its functionalities have been moved to the acpi_cpufreq module.

[Arnold J Noronha (arnold)]

On Thu, Mar 29, 2007 at 04:55:23PM -0000, Cesare Tirabassi wrote:
> Thanks for your cooperation Arnold.
> Please next time it would be better to not tar or compress attachments.
>
> >From a first glance, only thing that looks strange is concerning the
> speedstep_centrino module. I understand it is deprecated and most of its
> functionalities have been moved to the acpi_cpufreq module.

wow, yeah. I modprobed -r speedstep_centrino, modprobed acpi-cpufreq,
and things seem to be back to normal.

Is it possible that it is actually my fault, and that I have messed with
some files to make this happen? (Although I don't think I did.)

--Arnold

[Cesare Tirabassi (norsetto)]

No, it is not your fault.
The powernowd script which is launched during the initialisation do, among other things, load the cpufreq driver. This is choosen by calling another script, cpufreq-detect.sh.
This script loads, for the intel cpu with the est flag, the speedstep_centrino module.
This also means that, unless you change or disable this script, or that you force the unloading/loading of the modules through your own init scripts, that speedstep_centrino will always be loaded.

This is obviously wrong in light of this change in the recent kernels, and has to be corrected.

[Jarmo Ilonen (trewas)]

Speedstep-centrino (which is now used by default) gives worse frequency scaling choices for me too on Thinkpad X41, compared to acpi-cpufreq. With kernel linux-image-2.6.20-14-generic version 2.6.20-14.22 speedstep-centrino gives:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
798000 1064000 1330000 1596000

And with acpi-cpufreq:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1600000 1500000 1400000 1300000 1200000 1100000 1000000 900000 800000 600000

So the acpi-cpufreq gives more choices for the frequency and most importantly can go 200mhz lower. This used to work fine a few weeks back, I am not sure when it changed but I think it was kernel version 2.6.20-13. It has one suspicious comment in changelog,

linux-source-2.6.20 (2.6.20-13.21) feisty; urgency=low
  * speedstep-centrino: Include linux-phc built-in tables.
    - GIT-SHA fc9f7238d11d5a9ff03ce67fae0b5b5c9fd7f436
    - Bug #63789

How come speedstep-centrino is used anyway? It was disabled in

linux-source-2.6.20 (2.6.20-3.4) feisty; urgency=low
  * debian/config: Disable speedstep_centrino in favor of acpi_cpufreq.
    - GIT-SHA 2a0e7ef37fb8db5953f4c467219552835d7dddd8

and changelog doesn't mention reverting that.

[Arnold J Noronha (arnold)]

Its been quite a while now, the bug still exists.

I personally didn't find this a duplicate of bug #82242, where the OP talked of speedstep_centrino not getting loaded, which was not my case. Anyhow, the last post there is almost two months old.

I'm not a proper developer but I've got it working for me with the following patch to cpufreq-detech.sh:

--- /usr/share/powernowd/cpufreq-detect.sh.ubuntu 2007-04-18 09:58:17.000000000 +0530
+++ /usr/share/powernowd/cpufreq-detect.sh 2007-04-18 09:59:24.000000000 +0530
@@ -30,7 +30,7 @@
     # If the CPU has the est flag, it supports enhanced speedstep and should
     # use the speedstep-centrino driver
     if [ "`grep est $CPUINFO`" ]; then
- MODULE=speedstep-centrino;
+ MODULE=acpi-cpufreq;
     elif [ $CPU_FAMILY = 15 ]; then
     # Right. Check if it's a P4 without est.
        # Could be speedstep-ich, or could be p4-clockmod.

[Cesare Tirabassi (norsetto)]

Its not a question of being exactly the same problem, but of having the SAME solution (see last post of bug #82242):

The script /usr/share/powernowd/cpufreq-detect.sh would have to be modified to use acpi_cpufreq by default.
I'll take a look at the script.

Why this hasn't been done so far is unfortunately outside of my powers......

[Jarmo Ilonen (trewas)]

I removed the duplicate marking because this is a different bug than #82242. The bug is still alive and kicking in hardy (confirmed with live-cd from 2008-03-14).

The problem is that powernowd selects speedstep-centrino driver, which cannot use all available frequencies like the correct acpi-cpufreq driver (see details above in my comment from a year ago).

I am not sure if the bug was present in feisty and gutsy, because I fixed it locally by editing /etc/init.d/powernowd to use the correct driver. Anyway, after upgrading to hardy the bug came back.

[Arnold J Noronha (arnold)]

On Fri, Mar 14, 2008 at 12:22:24PM -0000, Jarmo Ilonen wrote:
> I am not sure if the bug was present in feisty and gutsy, because I
> fixed it locally by editing /etc/init.d/powernowd to use the correct
> driver. Anyway, after upgrading to hardy the bug came back.
>

Same here, this bug is definitely present in hardy.

[Scott James Remnant (Canonical) (canonical-scott)]

Fixed; all scaling drivers are now built into the kernel and we prefer acpi-cpufreq