Re: [gentoo-user] Power management updates?
On Wednesday 24 June 2009 03:28:55 Mike Mazur wrote: Hi, On Tue, Jun 23, 2009 at 04:44, Alan McKinnonalan.mckin...@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
Why does /sbin/rc not work when called from a script? (WAS: Re: [gentoo-user] Power management updates?)
Hi,
On Wed, Jun 24, 2009 at 17:50, Alan McKinnonalan.mckin...@gmail.com wrote:
On Wednesday 24 June 2009 03:28:55 Mike Mazur wrote:
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.
You mean grepping for the wrong string in syslog? I don't think that's
an issue, since pmg_switch_runlevel.sh is being called (as can be seen
by the log messages).
I looked inside /sbin/rc and discovered that control flow ends up at
the elsif statement on line 607. This is because $RUNLEVEL is S and
$argv1 is battery. The relevant code is:
elif [[ ( ${RUNLEVEL} == S || ${RUNLEVEL} == 1 ) ${argv1} != single ]]
then
level=$(awk -v level=${argv1} '
$2 == level {
split($0, fields, :)
print fields[2]
exit
}' /etc/inittab 2/dev/null)
[[ -z ${level} ]] level=3
/sbin/telinit ${level}
exit 0
fi
AFAICT, this code looks for the desired runlevel in /etc/inittab and
if that runlevel is there, we change to runlevel 3 (aka default). The
battery runlevel does not exist in /etc/inittab (and I'm pretty sure
it never did before), so the runlevel is never changed to battery.
What is interesting, though, is if I run `/sbin/rc battery` manually
from the command line, there are no problems and I find myself in the
battery runlevel. So I guess something has changed in /sbin/rc which
causes it to function differently when called from a script.
Does anyone know what's the proper way of calling /sbin/rc from a
script? Perhaps there are some parameters I should pass it to get the
runlevels to switch? I'm running sys-apps/baselayout-1.12.11.1 and it
doesn't seem to have a man page.
Thanks,
Mike
Re: [gentoo-user] Power management updates?
Hi, On Tue, Jun 23, 2009 at 04:44, Alan McKinnonalan.mckin...@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
Re: [gentoo-user] Power management updates?
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. Waay 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
