# cpufreqd malfuntion when on ac WITHOUT battery

## chrisruwe

Dear all,

cpufreqd scales the cpu fine both on battery and on ac. However, when the notebook is on ac and the battery is not present, cpufreq stops scaling and keeps the CPU on the lowest possible frequency.

Including a line battery [0%,100%] into the ac setting did not help at all.

After examining my cpufreqd.conf for the umpteenth time, I turn to the forums for help.

Thank you all, cheers, Chris

P.S.: I know that my settings are primitive at best, I tried to reduce complexity to facilitate my search for the error.

```

# this is a comment

# see CPUFREQD.CONF(5) manpage for a complete reference

[General]

pidfile=/var/run/cpufreqd.pid

poll_interval=2

verbosity=4

#enable_remote=1

#remote_group=root

[/General]

[acpi]

acpid_socket=/var/run/acpid.socket

[/acpi]

[Profile]

name=On Demand High

minfreq=20%

maxfreq=100%

policy=ondemand

[/Profile]

[Profile]

name=On Demand Low

minfreq=20%

maxfreq=80%

policy=ondemand

[/Profile]

##

# Basic states

##

[Rule]

name=AC Rule

ac=on                    # (on/off)

battery_interval=0-100 # attempt to kill battery not present issue, no success

profile=On Demand High

[/Rule]

 

[Rule]

name=AC Off - Low Battery

ac=off                   # (on/off)

battery_interval=0-30

#exec_post=echo 5 > /proc/acpi/sony/brightness

profile=On Demand Low

[/Rule]

[Rule]

name=AC Off - Medium Battery

ac=off                   # (on/off)

battery_interval=30-70

#exec_post=echo 5 > /proc/acpi/sony/brightness

profile=On Demand Low

[/Rule]

[Rule]

name=AC Off - High Power

ac=off                   # (on/off)

battery_interval=70-100

profile=On Demand Low

[/Rule]

```

P.S.:

Sorry for sleeping already. I am using cpufreqd-2.1.1 with USE=acpi sensors.

My emerge --info is:

```

Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.34-gentoo x86_64)

=================================================================

System uname: Linux-2.6.34-gentoo-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T6670_@_2.20GHz-with-gentoo-2.0.1

Timestamp of tree: Fri, 04 Jun 2010 00:30:01 +0000

app-shells/bash:     4.0_p37

dev-java/java-config: 2.1.10

dev-lang/python:     2.6.5-r2, 3.1.2-r3

dev-util/cmake:      2.6.4-r3

sys-apps/baselayout: 2.0.1

sys-apps/openrc:     0.6.1-r1

sys-apps/sandbox:    1.6-r2

sys-devel/autoconf:  2.13, 2.65

sys-devel/automake:  1.8.5-r4, 1.10.3, 1.11.1

sys-devel/binutils:  2.18-r3

sys-devel/gcc:       4.3.4, 4.4.3-r2

sys-devel/gcc-config: 1.4.1

sys-devel/libtool:   2.2.6b

virtual/os-headers:  2.6.30-r1

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="* -@EULA"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/X11/xkb"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

CXXFLAGS="-O2 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="assume-digests buildpkg distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"

GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/Mirrors/gentoo/"

LANG="en_GB.UTF-8"

LDFLAGS="-Wl,-O1"

LINGUAS="en en_GB en_US de"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="acl amd64 bash-completion berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 java mmx mmxext modules mudflap multilib ncurses nls nptl nptlonly nsplugin openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB en_US de" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 

Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## BradN

It's possible this is due to a bad AC adapter connection or an AC adapter that's beginning to fail and can't provide the required power (most newer laptops automatically throttle the CPU as needed to try and keep the machine running if AC+battery aren't enough), but it's possible this is a design decision to help avoid the possibility of running out of power from a cruddy AC connection when the battery is unavailable.  

Then again, maybe they're just trying to sell replacement batteries...

Unfortunately the easiest way to tell for sure is checking the behavior when running XP or similar.

----------

## chrisruwe

 *Quote:*   

> 
> 
> It's possible this is due to a bad AC adapter connection or an AC adapter that's beginning to fail and can't provide the required power (most newer laptops automatically throttle the CPU as needed to try and keep the machine running if AC+battery aren't enough),
> 
> 

 

Well, the machine concered is a Thinkpad bought last month, so I hope this is not the case.

 *Quote:*   

> 
> 
> but it's possible this is a design decision to help avoid the possibility of running out of power from a cruddy AC connection when the battery is unavailable.
> 
> 

 

A design-decision made by whom? The cpufreqd-makers? Like hard-coded? Because the rules don't tell anything about that.

 *Quote:*   

> 
> 
> Then again, maybe they're just trying to sell replacement batteries... 
> 
> 

 

Oh, what a ghastly idea! Surely, you cannot be serious. What kind of company would make decisions against the interest of it's customers for such selfish reasons?   :Wink: 

I think I will investigate further this weakend. A short run of xubuntu yielded that some kernel govenor sucessfully manages CPU freq, so there must be a solution. Thanks for your answer, though. Cheers, Chris

----------

## BradN

Sounds like it's a problem with your setup then and not some bizarre action triggered by the system itself.  Thinkpads are (were?) pretty well designed from a stability point of view.  If it's not a configuration problem but rather a bug in the kernel or cpufreqd then there should be bug reports or problem threads around for the googling, but that's not a bad idea in any case.

----------

