# power managment not working in battery runlevel.

## SVN

I have followed the Gentoo power managment guide, but the ondemand governor doesn't work in the battery runlevel. 

Running with ac, I get this:

```
cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 600 MHz - 1.70 GHz

  available frequency steps: 1.70 GHz, 1.70 GHz, 1.70 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz

  available cpufreq governors: ondemand, powersave, userspace, performance

  current policy: frequency should be within 600 MHz and 1.70 GHz.

                  The governor "performance" may decide which speed to use

                  within this range.

  current CPU frequency is 1.70 GHz (asserted by call to hardware).

```

 and speedstepping seems to be working.

Running on battery:

```
cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 600 MHz - 1.70 GHz

  available frequency steps: 1.70 GHz, 1.70 GHz, 1.70 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz

  available cpufreq governors: ondemand, powersave, userspace, performance

  current policy: frequency should be within 600 MHz and 600 MHz.

                  The governor "ondemand" may decide which speed to use

                  within this range.

  current CPU frequency is 600 MHz (asserted by call to hardware).

```

/etc/cpufreqd.conf:

```
[General]

pidfile=/var/run/cpufreqd.pid

poll_interval=2

pm_type=acpi

verbosity=5

[Profile]

name=ondemand

minfreq=600000

maxfreq=1700000

policy=ondemand

[Profile]

name=powersave

minfreq=600000

maxfreq=1700000

policy=powersave

[Profile]

name=performance

minfreq=600000

maxfreq=1700000

policy=performance

[Rule]

name=battery

ac=off

profile=ondemand

[Rule]

name=battery_low

ac=off

battery_interval=0-10

profile=powersave

[Rule]

name=ac

ac=on

profile=performance
```

Why there is "frequency should be within 600 MHz and 600 MHz"?

----------

## Earthwings

Your configuration seems to be ok. Verbosity is set to 5 so there should be some info on what cpufreqd is doing in the syslog. Does it indicate any problems? Can you post some lines of it when you switch from AC to battery?

----------

## SVN

```
May 22 11:33:22 asterix logger: Switching to battery runlevel

May 22 11:33:23 asterix cpufreqd: set_policy(): ondemand CPU0 600000 1700000.

May 22 11:33:23 asterix cpufreqd: main_loop(): profile set "ondemand" for rule "battery".

May 22 11:33:30 asterix logger: Switching to default runlevel

May 22 11:33:32 asterix cpufreqd: set_policy(): CPU0 600000 1700000.

May 22 11:33:32 asterix cpufreqd: main_loop(): profile set "performance" for rule "ac".

May 22 11:33:35 asterix logger: Switching to battery runlevel

May 22 11:33:36 asterix cpufreqd: set_policy(): ondemand CPU0 600000 1700000.

May 22 11:33:36 asterix cpufreqd: main_loop(): profile set "ondemand" for rule "battery".

May 22 11:33:38 asterix logger: Switching to default runlevel

May 22 11:33:40 asterix cpufreqd: set_policy(): performance CPU0 600000 1700000.

May 22 11:33:40 asterix cpufreqd: main_loop(): profile set "performance" for rule "ac".
```

Is there something wrong with pmg_ac_adapter?

```
event=ac_adapter AC 00000080 00000001

action=/etc/acpi/actions/pmg_switch_runlevel.sh %e

```

 I'm not sure about the event=... line

----------

## Earthwings

According to the syslog entries switching runlevels works perfectly and also cpufreqd is doing what you want it to. For some reason either cpufreqd pretends to write the max frequency, but doesn't do it, or there is an error writing the maximal frequency. Can you set the maximal frequency manually? That goes like 

```
cpufreq-set --max 1700MHz

cpufreq-info
```

----------

## SVN

I get the same output:

```
cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 600 MHz - 1.70 GHz

  available frequency steps: 1.70 GHz, 1.70 GHz, 1.70 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz

  available cpufreq governors: ondemand, powersave, userspace, performance

  current policy: frequency should be within 600 MHz and 600 MHz.

                  The governor "ondemand" may decide which speed to use

                  within this range.

  current CPU frequency is 600 MHz (asserted by call to hardware).

```

----------

## Earthwings

That's strange because cpufreq-info gets the hardware limits correctly. I guess it also doesn't work if you set it this way? 

```
echo -n 1700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

1700000
```

----------

## SVN

I get 600000  :Confused:  .

Does the event name in pmg_ac_adapter and pmg_battery have to be between " "?

----------

## Earthwings

It's not a problem with runlevel switching or acpid. I'm not sure if you need to quote the event string, but as runlevel switching is done, it seems to work.

Can you make a clean boot and append cpufreq.debug=7 as kernel parameter? Afterwards please post the output of dmesg.

----------

## SVN

dmesg output: here

I also see this now in the syslog:

```
May 22 19:46:47 asterix logger: ACPI group ac_adapter / action ac_adapter is not defined

May 22 19:46:47 asterix logger: ACPI group battery / action battery is not defined

May 22 19:46:47 asterix logger: ACPI group processor / action processor is not defined

May 22 19:46:49 asterix cpufreqd: set_policy(): ondemand CPU0 600000 1700000.

May 22 19:46:49 asterix cpufreqd: main_loop(): profile set "ondemand" for rule "battery".

May 22 19:46:56 asterix logger: ACPI group battery / action battery is not defined

May 22 19:46:56 asterix logger: ACPI group battery / action battery is not defined

```

----------

## Earthwings

 *SVN wrote:*   

> dmesg output: here

 

Can you remove the append= in front of cpufreq.debug=7? Otherwise it's not correctly recognized and debug verbosity is not increased.

 *Quote:*   

> 
> 
> I also see this now in the syslog:
> 
> ```
> ...

 

The "... is not defined" messages are generated from acpid's default /etc/acpi/default.sh

If you don't want to see them, edit the file and comment the "logger ..." lines in there.

----------

## SVN

 *Earthwings wrote:*   

> Can you remove the append= in front of cpufreq.debug=7? Otherwise it's not correctly recognized and debug verbosity is not increased.

 

If I do this, grub doesn't recognize it:

```
Kernel command line: ro root=/dev/hda8 vga=795 cpufreq.debug=7

Unknown boot option `cpufreq.debug=7': ignoring
```

But I noticed that everything is working if I start up with ac unplugged. I think there is something wrong with the runlevel switching.

----------

## Earthwings

 *SVN wrote:*   

>  *Earthwings wrote:*   Can you remove the append= in front of cpufreq.debug=7? Otherwise it's not correctly recognized and debug verbosity is not increased. 
> 
> If I do this, grub doesn't recognize it:
> 
> ```
> ...

 

Probably debugging support is missing in the kernel: 

```
  │ CONFIG_CPU_FREQ_DEBUG:                                                              │

  │                                                                                     │

  │ Say Y here to enable CPUfreq subsystem (including drivers)                          │

  │ debugging. You will need to activate it via the kernel                              │

  │ command line by passing                                                             │

  │    cpufreq.debug=<value>                                                            │

  │                                                                                     │

  │ To get <value>, add                                                                 │

  │      1 to activate CPUfreq core debugging,                                          │

  │      2 to activate CPUfreq drivers debugging, and                                   │

  │      4 to activate CPUfreq governor debugging
```

 *Quote:*   

> But I noticed that everything is working if I start up with ac unplugged. I think there is something wrong with the runlevel switching.

 

I am quite sure that it's not related to runlevel switching. Maybe you can temporarily disable it and boot with ac unplugged to verify. It may be that your laptop reports different settings to the kernel if booted from batteries. Did you check BIOS settings?

----------

## SVN

I also somtimes get these warnings:

```
May 23 21:10:37 asterix logger: Switching to default runlevel

May 23 21:10:37 asterix cpufreqd: set_policy(): performance CPU0 600000 1700000.

May 23 21:10:37 asterix cpufreqd: main_loop(): profile set "performance" for rule "ac".

May 23 21:10:43 asterix Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1700000, is 600000 kHz.

May 23 21:10:43 asterix cpufreqd: set_policy(): ondemand CPU0 600000 1700000.

May 23 21:10:43 asterix cpufreqd: main_loop(): profile set "ondemand" for rule "battery".

May 23 21:10:45 asterix Warning: CPU frequency is 1700000, cpufreq assumed 600000 kHz.

May 23 21:10:45 asterix cpufreqd: set_policy(): performance CPU0 600000 1700000.

May 23 21:10:45 asterix cpufreqd: main_loop(): profile set "performance" for rule "ac".
```

Tomorrow, I will compile my kernel with debug support and then, I hope to resolve the problem  :Wink: 

----------

## Earthwings

 *SVN wrote:*   

> May 23 21:10:43 asterix Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1700000, is 600000 kHz.
> 
> ...
> 
> May 23 21:10:45 asterix Warning: CPU frequency is 1700000, cpufreq assumed 600000 kHz.
> ...

 

That will be the source of the problem. Debugging might show more. I'm still hoping brodo joins the discussion  :Smile: 

----------

## SVN

dmesg (boot with adapter, unplugged adapter, plugged in again)

----------

## brodo

AFAICS the BIOS uses an ACPI mechanism to disable all but the lowest frequency steps while running on battery. This _may_ be to look good in some benchmarks, but this _may_ also be because the battery isn't strong enough for the CPU running at any other power level. Then you might risk (permanent) battery damage if you force it. otherwise, you can try to override it by patching the ACPI tables or the ACPI code. 

I have no patch ready, and need to run, so you'll likely have some delay in further replies from me....

----------

