public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] Power management updates?
@ 2009-06-22 13:56 Mike Mazur
  2009-06-22 20:44 ` Alan McKinnon
  0 siblings, 1 reply; 4+ messages in thread
From: Mike Mazur @ 2009-06-22 13:56 UTC (permalink / raw
  To: gentoo-user

Hello,

I noticed some issues with the power management setup I had when I
upgraded kernels over the last few months. This past weekend I decided
to crack down on this to see whether they could be fixed. I visited
the Gentoo Power Management Guide[1] again and re-traced the setup to
verify my system's behavior.

First issue is the runlevels are not switching properly when the AC
power adapter is un/plugged. When the power cable is unplugged, I see
the following entries in the syslog:

Jun 22 21:36:12 kitt logger: ACPI event unhandled: ac_adapter
ACPI0003:00 00000080 00000000
Jun 22 21:36:12 kitt logger: Switching to battery runlevel
Jun 22 21:36:13 kitt logger: ACPI event unhandled: processor
ACPI_CPU:00 00000081 00000000
Jun 22 21:36:13 kitt logger: ACPI event unhandled: processor
ACPI_CPU:01 00000081 00000000
Jun 22 21:36:13 kitt logger: ACPI event unhandled: battery PNP0C0A:00
00000080 00000001
Jun 22 21:36:13 kitt logger: Switching to battery runlevel

The syslog contains messages that the system is switching to runlevel
battery. These log messages are in
/etc/acpi/actions/pmg_switch_runlevel.sh. Unfortunately, the system
never changes from runlevel default; looking at
/var/lib/init.d/softlevel confirms this:

$ cat /var/lib/init.d/softlevel
default

When plugging the power back in, the syslog lacks the corresponding
"Switching to default runlevel" messages:

Jun 22 21:38:43 kitt logger: ACPI event unhandled: ac_adapter
ACPI0003:00 00000080 00000001
Jun 22 21:38:44 kitt logger: ACPI event unhandled: processor
ACPI_CPU:00 00000081 00000000
Jun 22 21:38:44 kitt logger: ACPI event unhandled: processor
ACPI_CPU:01 00000081 00000000
Jun 22 21:38:44 kitt logger: ACPI event unhandled: battery PNP0C0A:00
00000080 00000001

The second issue is with cpufreqd. When the power is unplugged, the
CPU scaling kicks in as expected, and the processors are cut to half
power (running at ~1GHz instead of their full capacity of ~2GHz). When
the AC adapter is plugged back in, the CPUs continue to operate at
only ~1GHz instead of being bumped back up to ~2GHz and I see messages
like this in my syslog:

Jun 22 21:38:44 kitt cpufreqd: cpufreqd_set_profile     : Couldn't set
profile "Performance High" set for cpu0 (1998000-1998000-performance)
Jun 22 21:38:44 kitt cpufreqd: cpufreqd_loop            : Cannot set
policy, Rule unchanged ("AC Off - High Power").

I pasted my /etc/cpufreqd.conf file at the end of this email.

The third issue seems to be with power management of my wireless card.
I have the iwl3945 wireless card. In older version of the kernel
(2.6.25 and before, I believe) this card was managed by a daemon in
userspace. After that the driver was merged into the kernel. I noticed
recently that the entry in /etc/conf.d/net (as per the Power
Management Guide) causes this error when the interface comes up:

 * Starting wlan0
Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not supported.
 *   wlan0 does not support the following configuration commands
 *     power on

I guess with the driver moving into the kernel, this setting has
changed as well. Is there another way to enable power management on my
wireless card? Is it still necessary?

Any input on these things would be much appreciated.

A few details:
I'm running gentoo-sources-2.6.30-r1
I updated a cpufreqd to version 2.3.4 by coping the version 2.2.1
.ebuild file into my local overlay and bumping the version
I updated the files installed by powermgmt-base with those in upstream
version 1.30

Thanks,
Mike


[1] http://www.gentoo.org/doc/en/power-management-guide.xml

# cat /etc/cpufreqd.conf
# this is a comment
# see CPUFREQD.CONF(5) manpage for a complete reference

[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=2
enable_plugin=acpi_ac, acpi_battery
enable_remote=1
remote_group=wheel
verbosity=4
[/General]

[acpi]
acpid_socket=/var/run/acpid.socket
[/acpi]

#[nforce2_atxp1]
#vcore_path=/some/path
#vcore_default=1500
#[/nforce2_atxp1]

#[sensors_plugin]
#sensors_conf=/some/file
#[/sensors_plugin]

[Profile]
name=On Demand High
minfreq=40%
maxfreq=100%
policy=ondemand
[/Profile]

[Profile]
name=On Demand Low
minfreq=20%
maxfreq=80%
policy=ondemand
[/Profile]

[Profile]
name=Performance High
minfreq=100%
maxfreq=100%
policy=performance
#exec_post=echo 8 > /proc/acpi/sony/brightness
[/Profile]

[Profile]
name=Performance Low
minfreq=80%
maxfreq=80%
policy=performance
[/Profile]

[Profile]
name=Powersave High
minfreq=70%
maxfreq=70%
policy=powersave
[/Profile]

[Profile]
name=Powersave Low
minfreq=30%
maxfreq=30%
policy=powersave
[/Profile]

#[Profile]
#name=Conservative High
#minfreq=33%
#maxfreq=100%
#policy=conservative
#[/Profile]
#
#[Profile]
#name=Conservative Low
#minfreq=0%
#maxfreq=66%
#policy=conservative
#[/Profile]

##
# Basic states
##
# when AC use performance mode
[Rule]
name=AC Rule
ac=on                    # (on/off)
profile=Performance High
[/Rule]

# conservative mode when not AC
[Rule]
name=AC Off - Low Battery
ac=off                   # (on/off)
battery_interval=0-30
#exec_post=echo 5 > /proc/acpi/sony/brightness
profile=Powersave Low
[/Rule]

# conservative mode when not AC
[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]

# stay in performance mode for the first minutes
[Rule]
name=AC Off - High Power
ac=off                   # (on/off)
battery_interval=70-100
#exec_post=echo 5 > /proc/acpi/sony/brightness
profile=On Demand High
[/Rule]

##
# Special Rules
##
# CPU Too hot!
[Rule]
name=CPU Too Hot
acpi_temperature=65-100
cpu_interval=50-100
profile=Performance Low
[/Rule]

# use performance mode if I'm watching a movie
# I don't care for batteries!
# But don't heat too much.
[Rule]
name=Movie Watcher
programs=xine,mplayer,gmplayer
battery_interval=0-100
acpi_temperature=0-60
profile=Performance High
[/Rule]



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-user] Power management updates?
  2009-06-22 13:56 [gentoo-user] Power management updates? Mike Mazur
@ 2009-06-22 20:44 ` Alan McKinnon
  2009-06-24  1:28   ` Mike Mazur
  0 siblings, 1 reply; 4+ messages in thread
From: Alan McKinnon @ 2009-06-22 20:44 UTC (permalink / raw
  To: gentoo-user

On Monday 22 June 2009 15:56:47 Mike Mazur wrote:
> Hello,
>
> I noticed some issues with the power management setup I had when I
> upgraded kernels over the last few months. This past weekend I decided
> to crack down on this to see whether they could be fixed. I visited
> the Gentoo Power Management Guide[1] again and re-traced the setup to
> verify my system's behavior.

I tossed that entire guide in the bin where it belongs a long time ago. 
Waaaaaay too complex, and seems to rely on faulty assumptions.

Dump cpufreqd. Use just the ondemand governor instead and get rid of the rest. 
It's better suited to how modern chips work anyway. You safe nothing and spend 
a great deal trying to fiddle cpu frequencies, and it's an expensive 
operation. Her'e what you *really* want the cpu to do:

Wake up periodically, go to state C0 *once*. Do work, do it quickly at full 
speed. Go back to sleep for as long as the cpu can. Remember, the cpu will 
still take the same number of clock cycles to complete a task, irrespective of 
what the frequency might be. The cpu is most efficient when running at it's 
design frequency, so let it do that and put it quickly into the lowest state 
you can get it into quickly. Then sleep.

[snip]

> The second issue is with cpufreqd. When the power is unplugged, the
> CPU scaling kicks in as expected, and the processors are cut to half
> power (running at ~1GHz instead of their full capacity of ~2GHz). When
> the AC adapter is plugged back in, the CPUs continue to operate at
> only ~1GHz instead of being bumped back up to ~2GHz and I see messages
> like this in my syslog:

That sounds like the conservative governor, the worst one of the lot. It 
forces the cpu to rapidly change state, and do it often. Changing C state is 
expensive, do it as seldom as you can. Just use ondemand all the time.

> The third issue seems to be with power management of my wireless card.
> I have the iwl3945 wireless card. In older version of the kernel
> (2.6.25 and before, I believe) this card was managed by a daemon in
> userspace. After that the driver was merged into the kernel. I noticed
> recently that the entry in /etc/conf.d/net (as per the Power
> Management Guide) causes this error when the interface comes up:

iwl3945 does not (yet) support this to the best of my knowledge. It also 
doesn't work here either.
-- 
alan dot mckinnon at gmail dot com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-user] Power management updates?
  2009-06-22 20:44 ` Alan McKinnon
@ 2009-06-24  1:28   ` Mike Mazur
  2009-06-24  9:50     ` Alan McKinnon
  0 siblings, 1 reply; 4+ messages in thread
From: Mike Mazur @ 2009-06-24  1:28 UTC (permalink / raw
  To: gentoo-user

Hi,

On Tue, Jun 23, 2009 at 04:44, Alan McKinnon<alan.mckinnon@gmail.com> wrote:
> On Monday 22 June 2009 15:56:47 Mike Mazur wrote:
>> <SNIP>
>> I noticed some issues with the power management setup I had when I
>> upgraded kernels over the last few months. This past weekend I decided
>> to crack down on this to see whether they could be fixed. I visited
>> the Gentoo Power Management Guide[1] again and re-traced the setup to
>> verify my system's behavior.
>
> Dump cpufreqd. Use just the ondemand governor instead and get rid of the rest.
>
> <SNIP>
>
> That sounds like the conservative governor, the worst one of the lot. It
> forces the cpu to rapidly change state, and do it often. Changing C state is
> expensive, do it as seldom as you can. Just use ondemand all the time.

You mean set the default governor to "ondemand" in the kernel and
leave it at that regardless of whether running on batter or AC power?

>
>> The third issue seems to be with power management of my wireless card.
>> I have the iwl3945 wireless card. In older version of the kernel
>> (2.6.25 and before, I believe) this card was managed by a daemon in
>> userspace. After that the driver was merged into the kernel. I noticed
>> recently that the entry in /etc/conf.d/net (as per the Power
>> Management Guide) causes this error when the interface comes up:
>
> iwl3945 does not (yet) support this to the best of my knowledge. It also
> doesn't work here either.

Alright, this makes sense I guess.

Still one issue remains -- why are my RC states not automatically
switched between default and battery even though my acpid setup is
right and works (according to the log messages)?

Thanks,
Mike



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-user] Power management updates?
  2009-06-24  1:28   ` Mike Mazur
@ 2009-06-24  9:50     ` Alan McKinnon
  0 siblings, 0 replies; 4+ messages in thread
From: Alan McKinnon @ 2009-06-24  9:50 UTC (permalink / raw
  To: gentoo-user

On Wednesday 24 June 2009 03:28:55 Mike Mazur wrote:
> Hi,
>
> On Tue, Jun 23, 2009 at 04:44, Alan McKinnon<alan.mckinnon@gmail.com> wrote:
> > On Monday 22 June 2009 15:56:47 Mike Mazur wrote:
> >> <SNIP>
> >> I noticed some issues with the power management setup I had when I
> >> upgraded kernels over the last few months. This past weekend I decided
> >> to crack down on this to see whether they could be fixed. I visited
> >> the Gentoo Power Management Guide[1] again and re-traced the setup to
> >> verify my system's behavior.
> >
> > Dump cpufreqd. Use just the ondemand governor instead and get rid of the
> > rest.
> >
> > <SNIP>
> >
> > That sounds like the conservative governor, the worst one of the lot. It
> > forces the cpu to rapidly change state, and do it often. Changing C state
> > is expensive, do it as seldom as you can. Just use ondemand all the time.
>
> You mean set the default governor to "ondemand" in the kernel and
> leave it at that regardless of whether running on batter or AC power?

Yes.

> >> The third issue seems to be with power management of my wireless card.
> >> I have the iwl3945 wireless card. In older version of the kernel
> >> (2.6.25 and before, I believe) this card was managed by a daemon in
> >> userspace. After that the driver was merged into the kernel. I noticed
> >> recently that the entry in /etc/conf.d/net (as per the Power
> >> Management Guide) causes this error when the interface comes up:
> >
> > iwl3945 does not (yet) support this to the best of my knowledge. It also
> > doesn't work here either.
>
> Alright, this makes sense I guess.
>
> Still one issue remains -- why are my RC states not automatically
> switched between default and battery even though my acpid setup is
> right and works (according to the log messages)?

The simplest answer (usually the right one) is that you are probably grepping 
for the wrong string. These things are subject to change and there's no easy 
way for you to find out when it happens.

-- 
alan dot mckinnon at gmail dot com



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-06-24  9:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-22 13:56 [gentoo-user] Power management updates? Mike Mazur
2009-06-22 20:44 ` Alan McKinnon
2009-06-24  1:28   ` Mike Mazur
2009-06-24  9:50     ` Alan McKinnon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox