Bug 399068

Created attachment 221353 [details]
cpufreq-info when on A/C

Created attachment 221354 [details]
cpufreq-info when on battery

I have a few questions here.

If you are using kpowersave, why are you doing this dance with a pm-utils hook and doing cpufreq-set, working around all infrastructure that is in place for setting your cpu frequency?
Why don't you just use the "Configure Kpowersave" dialog and configure the two schemes for "Performance" (default for "on AC") and "Powersave" (default for "on battery") to do what you want.

Unless you have a very good reason to do this, i am inclined to close this report as "INVALID".

Hi,

You ask:

   Why are you doing this dance with a pm-utils hook
   and doing cpufreq-set,

and your flippant question was already answered in the initial submission:

   If I don't do this, the policy
   remains at 800 MHz.

Regardless, I believe your question is:

   Have you configured `kpowersave's "on battery" to be "dynamic".

Answer:  yes.

I'd like the frequency to ramp-up when there's a need.  I want this ramp-up to happen regardless of whether I'm on AC ("Performance") or on Battery ("Powersave").

The ramp-up works when I'm on AC (aka Performance).  I have its `Set CPU Frequency Policy' set to `Dynamic'  I did the same for Powersave however Powersave doesn't work this way.

I've even set the `Default Schemes' for AC _and_ Battery to be `Performance'

I hope the above makes sense.

Let me know if you'd like .png's of my KPowersave settings.

Cheers

Well, the important part that was missing is, that you already tried to configure it in kpowersave.
So it seems the hal-cpufreq-addon has a problem switching the governors on your machine, which might be a kernel or an userspace issue.

=> reassigning to the author of the cpufreq addon.

You could try if it helps to change your pm-utils hook to use "powersave -A" instead of cpufreq-set (after the sleep 20). This would mean that the kernel needs ~20 seconds after an AC power change before it is possible to set the cpu frequency again. If this does not work, but cpufreq-set works (which command exactly?), then it might also indicate a problem with the cpufreq-addon.

BTW, this line from cpufreq-info on battery:
  current policy: frequency should be within 800 MHz and 800 MHz.
makes me wonder if this is kind of a duplicate of bug 396311...

When you're on battery, please post the output of:

$ cd /sys/devices/system/cpu/cpu0/cpufreq
$ cat scaling_governor scaling_min_freq scaling_max_freq

Kpowersave is only able to set the governor, so if it's 'ondemand', this bug is a duplicate of 396311.

(In reply to comment #7 from Holger Macht)
> Kpowersave is only able to set the governor, so if it's 'ondemand', this bug > is a duplicate of 396311.

Not necessarily. KPowersave can fall back on DYNAMIC to the userspace or the 
conservative governor.

I've removed the call `cpufreq-set' in my pm hook script.  Just to remove that variable from the equation.

What I've noticed is if I wait for 20-40 seconds, `cpufreq-info' reports a policy betweenn 800 MHz and 2.40 GHz.  Hmmm.

Perhaps the above is what Danny is alluding to?  Danny?

Holger, here's the output of `scaling_governor scaling_min_freq scaling_max_freq'

   ondemand
   800000
   2401000

Please advise and thank you for the help.

So just to make clear, after about 20 to 40 seconds, everything works ok?

Hi Holger,

I was more rigorous in my test this time and it's true, after 16 to 17 seconds, the frequency is okay.  

Shouldn't the change be instantaneous?  It is when I switch to AC before the 17 seconds have elapsed and I'm on Battery.

My test:

o konsole #1:  while [ 1 ] ; do echo x; done

o konsole #2:  while [ 1 ] ; do date; cpufreq-info | grep 'current policy:'; sleep 1; done

Not sure, might be a kernel issue, which I doubt, or more likely the BIOS is interfering somehow. Do you have the lates BIOS for your machine?

No, the BIOS on my laptop is A06 (for documentation purposes) and the latest is A11.  I'll upgrade the BIOS now and see what happens.  brb

I also agree with you reclassifying this issue as minor.

Hi,

I upgraded to A11 and the behavior is the same:  it takes about 16 seconds for the frequency to be `adjusted'

I'm not sure if anything should be done ... I could always force my hook script to force the setting for the first 16 seconds.  <g>

Thomas, any idea what could be wrong here? Kernel issue? Short summary:

- latest BIOS
- after unpluggin the system from AC source, it takes about 20 to 40 seconds for the ondemand governor to be able to increase frequency

If not, I would consider this bug as WONTFIX, or CANTFIX ;)

A slight correction:  20 to 40 seconds => 16 to 17 seconds; otherwise spot on!  Even on the CANTFIX!  :)

You might want to run acpi_listen in a separate shell while testing.
If you see a processor event when the limit gets active (or in-active) this likely is a kernel or BIOS issue.

I saw something similar on Dells. Freq was limited for some secondes when un- or plugging AC adapter.
For about 5 secs, freq was limited. This was a (intended?) BIOS issue, nothing could be done about.

Hi Thomas,

FYI: this is a Dell M4300

The `acpi_listen' output is included in-line.  My comments are in `#':

---8-<-----8-<--
#
# Immediately after unplugging AC; on battery
#
# Using simple shell script, I sleep/poll every second
# and note the frequency range is 800MHz - 800MHz
#
ac_adapter AC 00000080 00000000
processor CPU0 00000080 00000005
processor CPU1 00000080 00000005
battery BAT0 00000080 00000001

#
# After 16 to 17 seconds, frequency range
# 800MHz - 2.4GHz and the following event
# coincides with the monitor script's report
#
processor CPU0 00000080 00000000
processor CPU1 00000080 00000000
---8-<-----8-<--

When someone of the mobile team has contact with DELL they should ask what they intend to do here or whether this is intended at all.
DELL BIOSes also have the odd nature to switch the frequency by BIOS (and not tell the OS to do so -> they should change this also, nobody else does it...).

BIOS bug/feature -> invalid.