Bug 700340

The output looks quite strange.

Is your cpufreq driver (acpi-cpufreq in this case, I suppose) loaded at that time? Is the ondemand governor really used?

Try 'cpupower frequency-info'.

This is the output of 'cpupower frequency-info' when CPU scaling is working:

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 2.53 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.53 GHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

Does it tell you anything?

I'll try to get the output of the same command when CPU scaling doesn't work.

(In reply to comment #2)
> This is the output of 'cpupower frequency-info' when CPU scaling is working:
> 
> analyzing CPU 0:
>   driver: acpi-cpufreq
>   CPUs which run at the same hardware frequency: 0 1
>   CPUs which need to have their frequency coordinated by software: 0
>   maximum transition latency: 10.0 us.
>   hardware limits: 800 MHz - 2.53 GHz
>   available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
>   available cpufreq governors: ondemand, userspace, performance
>   current policy: frequency should be within 800 MHz and 2.53 GHz.
>                   The governor "ondemand" may decide which speed to use
>                   within this range.
>   current CPU frequency is 2.53 GHz (asserted by call to hardware).
>   boost state support: 
>     Supported: no
>     Active: no
> 
> Does it tell you anything?

This looks just how it should.

> 
> I'll try to get the output of the same command when CPU scaling doesn't work.

That would be more helpful.

Thanks :)

Ok, here is the output of 'cpupower frequency-info' when CPU scaling is not working:

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

Another observation:
I've rebooted the laptop several times and CPU frequency scaling worked after every reboot. Each time the laptop was docked in the docking station.

After undocking and restarting it, CPU frequency scaling didn't work.
This time even executing 'service cpuspeed restart' didn't help.

Next I connected the AC power cable to the computer and tried restarting cpuspeed. Again, no change.

However, after putting the laptop back in the docking station and restarting cpuspeed daemon, the CPU frequency scaling works again. The output of 'cpupower frequency-info' is:
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 2.53 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.53 GHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

Thank you, Tadej.

This looks like either kernel or BIOS issue. I bet on the latter.
Any chance your BIOS tries to be clever and adjusts the hardware limits for you?

(In reply to comment #5)
> This looks like either kernel or BIOS issue. I bet on the latter.
> Any chance your BIOS tries to be clever and adjusts the hardware limits for
> you?

Hmm... I don't know how I can check that?

I have a 2.5 year old HP EliteBook 8530p and I haven't updated its BIOS for a while.
I'm not sure when these CPU scaling issues started, but they are not so old (I would say I noticed then 2-3 mounts ago) and I couldn't link them with any of the BIOS updates.

Is it possible that some service (e.g. tuned) is governing the minimum and maximum frequency of the CPU depending on the power state (e.g. on battery, on AC power)?

(In reply to comment #6)
> (In reply to comment #5)
> > This looks like either kernel or BIOS issue. I bet on the latter.
> > Any chance your BIOS tries to be clever and adjusts the hardware limits for
> > you?
> 
> Hmm... I don't know how I can check that?
> 

Possibly just looking around in your BIOS for some power management stuff.

> I have a 2.5 year old HP EliteBook 8530p and I haven't updated its BIOS for a
> while.
> I'm not sure when these CPU scaling issues started, but they are not so old (I
> would say I noticed then 2-3 mounts ago) and I couldn't link them with any of
> the BIOS updates.
> 
> Is it possible that some service (e.g. tuned) is governing the minimum and
> maximum frequency of the CPU depending on the power state (e.g. on battery, on
> AC power)?

I don't know. I've added tuned owner to CC for some more insight.

Hi Petr & Tadej.

In regards to CPU tuning currently tuned only uses the PM_QOS feature to change the latency for collapsed wakeups. This shouldn't affect minimum or maximum frequency in the kernel.

The only other thing we do, but thats part of the ktune static tuning parameters that for some cases we enabled the ondemand CPU governor. This is typically already the default for all systems, so it shouldn't affect behaviour for you either.

We specifically don't do hard downscaling of CPU frequency as it is actually counter productive to performance and power saving due to the "race to idle" concept:

When your machine wakes up to perform some work it is practically always better to clock the CPU at it's maximum at that point to do perform the work as quickly as possible so it can go to sleep quicker again too, resulting in the CPU being longer in deep sleep stats and saving more power. Clocking the CPU up and down is extraordinarily quick, especially compared to switching C states.

So to summarize, this hard downclocking of the CPU seems to happen somewhere else, but i'm afraid i don't know where.

Thanks & regards, Phil

Thank you Phil for your comprehensive answer!

Today I tried what happends with a prerelease of F-15. I used the GNOME3 test day image available from: http://adamwill.fedorapeople.org/gnome3-test-20110421/gnome-20110419-x86_64.iso

Version of the kernel is: kernel-2.6.38.3-15.rc1.fc15.x86_64

A booted the laptop unplugged (without AC power). Results are the same as with F-14:
[root@localhost liveuser]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no
[root@localhost liveuser]# service cpuspeed restart
Restarting cpuspeed (via systemctl):                       [  OK  ]
[root@localhost liveuser]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 2.53 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

I assume you didn't plug it in before the restart, did you?

Could you boot in single-user mode via adding a "1" to the kernel boot commandline?

Simply enter grub during bootup, edit the 2nd entry via "e" and add " 1" to it, press ESC and "b" should do the trick. If the output of "cpupower frequency-info" later on is again limiting the frequency to 800Mhz that would be really strange.

Thanks & regards, Phil

Hi!

First, sorry for the big delay, I hadn't had the time to pursue this further.

Today I played with this again and the results are the following:

Version(s) of the applicable packages:
kernel-2.6.38.8-32.fc15.x86_64
cpupowerutils-009-0.3.p1.fc15.x86_64
cpuspeed-1.5-15.fc15.x86_64

I used Phil's suggestion and always booted the computer to the single-user mode (via " 1" boot parameter).

When booting the laptop on battery (without AC power), I get the following:
[root@tlinux64 tadej]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

(I rebooted 5 times and the result was always the same).
Interestingly, performing 'service cpuspeed restart' didn't help to resolve the issue.

When booting the laptop on AC power, I get the following:
[root@tlinux64 tadej]# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.53 GHz
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 800 MHz and 2.53 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.53 GHz (asserted by call to hardware).
  boost state support: 
    Supported: no
    Active: no

(Again, I rebooted 5 times and the result was always the same).

Has anyone any suggestion?

I still think the same as I did in Comment 5.
Something (like BIOS) says the maximum CPU frequency is 800MHz when you're running on battery.  The ondemand governor won't go above that, of course.

OK, after the results of comment #12 i have to agree with Petr here. If you get those settings booting in single user mode then either the BIOS or the kernel itself would need to limit the CPU freq to 800 mhz. And as you are using the ondemand governor which doesn't do that the only remaining cause is the HW or BIOS itself of your system.

And using cpufreq later one probably then allows the system sometimes to actually be able to scale up the frequency (so it's actually helping here. ;)).

Thanks & regards, Phil

Thanks, Phil.

Tadej, I don't know what's really behind this behavior in your case but it's certainly not a cpuspeed issue, hence I'm closing this now.

Good luck finding the cause :)

Petr and Phil,

thank you for your insightful and patient comments!