# CPU scaling locks at minimum freq

## pettsson

Hi!

I've got a problem with freq scaling on my laptop (Dell Vostro 1400, Core2Duo T7250 2Ghz). For some reason, when on external power (which is almost always, since battery time is down to ~20 minutes...) the only availible state is 800 MHz. Looking at /var/log/messages, this is what happens when disconnecting and connecting external power:

```

# Unplug

Mar 21 21:16:42 localhost logger: ACPI event unhandled: battery BAT0 00000080 00000001

Mar 21 21:16:58 localhost logger: ACPI event unhandled: processor CPU0 00000080 00000000

Mar 21 21:16:58 localhost logger: ACPI event unhandled: processor CPU1 00000080 00000000

# Plug in

Mar 21 21:17:45 localhost kernel: [ 1088.441293] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).

Mar 21 21:17:45 localhost kernel: [ 1088.441304] atkbd serio0: Use 'setkeycodes e00d <keycode>' to make it known.

Mar 21 21:17:46 localhost logger: ACPI event unhandled: processor CPU0 00000080 00000004

Mar 21 21:17:46 localhost logger: ACPI event unhandled: processor CPU1 00000080 00000004

Mar 21 21:17:46 localhost logger: ACPI event unhandled: battery BAT0 00000080 00000001

```

Reading around the internet, the event "CPUn 00000080 00000004" seems to disallow frequency states 0-3 (which are "2.00 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz", according to /proc/cpuinfo. The two 2GHz's are because the highest state is really 2001 MHz, for some reason). Why is this run when connecting? 

I've tried running/not running cpufrequtils, disabling the userspace frequency tool (E17 cpufreq module) restarting acpid and whatnot, but I can't find a way to get around it. Any ideas? Could it be related to the wierd "atkbd serio0" thing? It seems to be connected to the plugging in of power.

----------

## Jaglover

What governors you have enabled in the kernel and which one is set default.

----------

## pettsson

Default is userspace (tried enabling all of them, didn't help though):

```

# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set

CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y

# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set

# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set

CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=y

CONFIG_CPU_FREQ_GOV_USERSPACE=y

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

CONFIG_CPU_IDLE_GOV_LADDER=y

CONFIG_CPU_IDLE_GOV_MENU=y

```

----------

## Jaglover

Try emerging sys-power/cpufrequtils, then use cpufreq-set to enable ondemand or performance.

----------

## pettsson

I already have cpufrequtils (I mentioned trying with disabling the init-script). Setting the governor does not help, neither does 'cpufreq-set -u 2Ghz', it's still locked to only using 800 MHz. 

As I understand it, acpid (or some even lower level) disallows using power states > 800 MHz - unless *not* using external power.

----------

## Jaglover

Have you set it up properly in the BIOS?

----------

## pettsson

Yes, I think so. The BIOS isn't very verbose in the meaning of the options, but it looks ok, and it has worked before. I don't remember when it stopped working, but possibly something like 4-5 months ago. It took a while until I realised why the comp was so awfully slow all the time. Last time I updated acpid before I noticed it was in August however, and I know it's been working after that. Any other likely packages I could check?

----------

## Yamakuzure

Maybe your problem is the same I had on my laptop:

Whenever I unplugged AC power, acpid correctly switched the runlevel and the governor (from "performance" to "conservative") as I configured in /etc/acpi/default.sh.

But when I plugged in AC power, although it looked like everything is working fine, runlevel change, cpufreq-info stated the CPUs to be driven by the right governor ("performance"), the MHz stayed at minimum. Both conky and cpufreq-info showed the minimal MHz, nothing more.

The solution for me was:

/etc/init.d/cpufreqd restart

after plugging in AC. Since then everything is working fine again.

----------

## pettsson

Ok, so I kinda solved it, but I'd like to know if there are any reprecussions. Adding a empty action in /etc/acpi/default.sh which catches the CPU events, all works as expected. But it seems like a kludge solution, right?

----------

## pettsson

Disregard that, must have been something else. After a reboot, the problem is back.

However, on that reboot i noticed a warning about it thinking my AC adapter was not genuine. Looked into it a bit more, and discovered that my battery was not charging when connected, just not discharging. Switched to a spare adapter, and now there aren't any slow-down events logged (yes, I did remove the catch-all I wrote about above). So probably the BIOS did not recognise my adapter, and thus scaled down.

----------

