/[gentoo]/xml/htdocs/doc/en/power-management-guide.xml
Gentoo

Contents of /xml/htdocs/doc/en/power-management-guide.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.12 - (show annotations) (download) (as text)
Wed May 4 16:54:18 2005 UTC (9 years, 5 months ago) by neysx
Branch: MAIN
Changes since 1.11: +215 -208 lines
File MIME type: application/xml
#91043 introduce cpufrequtils for easier problem detection...

1 <?xml version='1.0' encoding="UTF-8"?>
2 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/power-management-guide.xml,v 1.11 2005/04/18 19:19:27 dertobi123 Exp $ -->
4 <guide link="power-management-guide.xml">
5 <title>Power Management Guide</title>
6
7 <author title="Author">
8 <mail link="fragfred@gmx.de">Dennis Nienhüser</mail>
9 </author>
10
11 <abstract>
12 Power Management is the key to extend battery run time on mobile systems like
13 laptops. This guide assists you setting it up on your laptop.
14 </abstract>
15
16 <!-- The content of this document is licensed under the CC-BY-SA license -->
17 <!-- See http://creativecommons.org/licenses/by-sa/2.0 -->
18 <license/>
19
20 <version>1.22</version>
21 <date>2005-05-04</date>
22
23 <chapter>
24 <title>Introduction</title>
25 <section>
26 <title>Why Power Management?</title>
27 <body>
28
29 <p>
30 Capacity and lifetime of laptop batteries has improved much in the last years.
31 Nevertheless modern processors consume much more energy than older ones and
32 each laptop generation introduces more devices hungry for energy. That's why
33 Power Management is more important than ever. Increasing battery run time
34 doesn't necessarily mean buying another battery. Much can be achieved applying
35 intelligent Power Management policies.
36 </p>
37
38 </body>
39 </section>
40
41 <section>
42 <title>A quick overview</title>
43 <body>
44
45 <p>
46 Please notice that this guide describes Power Management for <e>laptops</e>.
47 While some sections might also suite for <e>servers</e>, others do not and may
48 even cause harm. Please do not apply anything from this guide to a server
49 unless you really know what you are doing.
50 </p>
51
52 <p>
53 As this guide has become rather long, here's a short overview helping you to
54 find your way through it.
55 </p>
56
57 <p>
58 The <e>Prerequisites</e> chapter talks about some requirements that should be
59 met before any of the following device individual sections will work. This
60 includes BIOS settings, kernel configuration and some simplifications in user
61 land. The following three chapters focus on devices that typically consume most
62 energy - processor, display and hard drive. Each can be configured seperately.
63 <e>CPU Power Management</e> shows how to adjust the processor's frequency to
64 save a maximum of energy whithout losing too much performance. A few different
65 tricks prevent your hard drive from working unnecessarily often in <e>Disk Power
66 Management</e> (decreasing noise level as a nice side effect). Some notes on
67 Wireless LAN and USB finish the device section in <e>Power Management for other
68 devices</e> while another chapter is dedicated to the (rather experimental)
69 <e>sleep states</e>. Last not least <e>Troubleshooting</e> lists common
70 pitfalls.
71 </p>
72
73 </body>
74 </section>
75
76 <section>
77 <title>Power Budget for each component</title>
78 <body>
79
80 <figure link="/images/energy-budget.png" short="Which component consumes how
81 much energy?" caption="Power budget for each component"/>
82
83 <p>
84 Nearly every component can operate in different states - off, sleep, idle,
85 active to name a few - consuming a different amount of energy. Major parts are
86 consumed by the LCD display, CPU, chipset and hard drives. Often one is able to
87 activate OS-independent Power Management in the BIOS, but an intelligent setup
88 in the operating system adapting to different situations can achieve much more.
89 </p>
90
91 </body>
92 </section>
93 </chapter>
94
95 <chapter>
96 <title>Prerequisites</title>
97 <section>
98 <title>What has to be done first</title>
99 <body>
100
101 <p>
102 Before going into the details on making individual devices Power Management
103 aware, make sure certain requirements are met. After controlling the BIOS
104 settings, some kernel options want to be enabled - these are in short ACPI,
105 sleep states and CPU frequency scaling. As power saving most of the time comes
106 along with performance loss or increased latency, it should only be enabled
107 when running on batteries. That's where a new runlevel <e>battery</e> comes in
108 handy.
109 </p>
110
111 </body>
112 </section>
113 <section>
114 <title>The BIOS part</title>
115 <body>
116
117 <p>
118 First have a look into your BIOS Power Management settings. The best way is to
119 combine BIOS and operating system policies, but for the moment it's better to
120 disable most of the BIOS part. This makes sure it doesn't interfere with your
121 policies. Don't forget to re-check BIOS settings after you configured
122 everything else.
123 </p>
124
125 </body>
126 </section>
127 <section>
128 <title>Configuring the kernel</title>
129 <body>
130
131 <p>
132 ACPI (Advanced Configuration and Power Interface) support in the kernel is
133 still work in progress. Using a recent kernel will make sure you'll get the
134 most out of it.
135 </p>
136
137 <p>
138 In kernel config, activate at least these options:
139 </p>
140
141 <pre caption="Minimum kernel setup for Power Management (Kernel 2.6)">
142 Power Management Options ---&gt;
143 [*] Power Management Support
144 [ ] Software Suspend
145 [ ] Suspend-to-Disk Support
146
147 ACPI( Advanced Configuration and Power Interface ) Support ---&gt;
148 [*] ACPI Support
149 [ ] Sleep States
150 [*] AC Adapter
151 [*] Battery
152 &lt;M&gt; Button
153 &lt;M&gt; Fan
154 &lt;M&gt; Processor
155 &lt;M&gt; Thermal Zone
156 &lt; &gt; ASUS/Medion Laptop Extras
157 &lt; &gt; Toshiba Laptop Extras
158 [ ] Debug Statements
159
160 CPU Frequency Scaling ---&gt;
161 [*] CPU Frequency scaling
162 Default CPUFreq governor (userspace)
163 &lt;*&gt; 'performance' governor
164 &lt;*&gt; 'powersave' governor
165 &lt;*&gt; 'ondemand' cpufreq policy governor
166 &lt;*&gt; CPU frequency table helpers
167 &lt;M&gt; ACPI Processor P-States driver
168 &lt;*&gt; <i>CPUFreq driver for your processor</i>
169 </pre>
170
171 <p>
172 Decide yourself whether you want to enable Software Suspend, Suspend-to-Disk and
173 Sleep States (see below). If you own an ASUS, Medion or Toshiba laptop, enable
174 the appropriate section.
175 </p>
176
177 <p>
178 The kernel has to know how to enable CPU frequency scaling on your processor. As
179 each type of CPU has a different interface, you've got to choose the right
180 driver for your processor. Be careful here - enabling <e>Intel Pentium 4 clock
181 modulation</e> on a Pentium M system will lead to strange results for example.
182 Consult the kernel documentation if you're unsure which one to take.
183 </p>
184
185 <p>
186 Compile your kernel, make sure the right modules get loaded at startup and boot
187 into your new ACPI-enabled kernel. Next run <c>emerge sys-power/acpid</c> to get
188 the acpi daemon. This one informs you about events like switching from AC to
189 battery or closing the lid. Make sure the modules are loaded if you didn't
190 compile them into the kernel and start acpid by executing
191 <c>/etc/init.d/acpid start</c>. Run <c>rc-update add acpid default</c> to load
192 it on startup. You'll soon see how to use it.
193 </p>
194
195 <pre caption="Installing acpid">
196 # <i>emerge sys-power/acpid</i>
197 # <i>/etc/init.d/acpid start</i>
198 # <i>rc-update add acpid default</i>
199 </pre>
200
201 </body>
202 </section>
203 <section>
204 <title>Creating a "battery" runlevel</title>
205 <body>
206
207 <p>
208 The default policy will be to enable Power Management only when needed -
209 running on batteries. To make the switch between AC and battery convenient,
210 create a runlevel <e>battery</e> that holds all the scripts starting and
211 stopping Power Management.
212 </p>
213
214 <note>
215 You can safely skip this section if you don't like the idea of having another
216 runlevel. However, skipping this step will make the rest a bit trickier to set
217 up. The next sections assume a runlevel <e>battery</e> exists.
218 </note>
219
220 <pre caption="Creating a battery runlevel">
221 # <i>cd /etc/runlevels</i>
222 # <i>cp -a default battery</i>
223 </pre>
224
225 <p>
226 Finished. Your new runlevel <e>battery</e> contains everything like
227 <e>default</e>, but there is no automatic switch between both yet. Time to
228 change it.
229 </p>
230
231 </body>
232 </section>
233 <section>
234 <title>Reacting on ACPI events</title>
235 <body>
236
237 <p>
238 Typical ACPI events are closing the lid, changing the power source or pressing
239 the sleep button. An important event is changing the power source, which should
240 cause a runlevel switch. Create the following files to switch between
241 <e>default</e> and <e>battery</e> runlevel depending on the power source:
242 </p>
243
244 <pre caption="/etc/acpi/actions/pmg_switch_runlevel.sh">
245 #!/bin/bash
246
247 <comment># BEGIN configuration</comment>
248 RUNLEVEL_AC="default"
249 RUNLEVEL_BATTERY="battery"
250 <comment># END configuration</comment>
251
252
253 if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]
254 then
255 logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."
256 exit 1
257 fi
258
259 if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]
260 then
261 logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."
262 exit 1
263 fi
264
265 if on_ac_power
266 then
267 if [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
268 then
269 logger "Switching to ${RUNLEVEL_AC} runlevel"
270 /sbin/rc ${RUNLEVEL_AC}
271 fi
272 elif [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
273 then
274 logger "Switching to ${RUNLEVEL_BATTERY} runlevel"
275 /sbin/rc ${RUNLEVEL_BATTERY}
276 fi
277 </pre>
278
279 <pre caption="/etc/acpi/events/pmg_ac_adapter">
280 <comment># replace "ac_adapter" below with the event generated on your laptop</comment>
281 <comment># See /var/log/acpid</comment>
282 event=ac_adapter.*
283 action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
284 </pre>
285
286 <pre caption="/etc/acpi/events/pmg_battery">
287 <comment># replace "battery" below with the event generated on your laptop</comment>
288 <comment># See /var/log/acpid</comment>
289 event=battery.*
290 action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
291 </pre>
292
293 <p>
294 Additionally you need the package sys-power/powermgmt-base which contains
295 the <c>on_ac_power</c> utility. The file <path>pmg_switch_runlevel.sh</path>
296 must be executable.
297 </p>
298
299 <pre caption="Finishing runlevel switching with acpid">
300 <i># emerge powermgmt-base</i>
301 <i># chmod +x /etc/acpi/actions/pmg_switch_runlevel.sh</i>
302 <i># /etc/init.d/acpid restart</i>
303 </pre>
304
305 <p>
306 Give it a try: Plug AC in and out and watch syslog for the "Switching to AC
307 mode" or "Switching to battery mode" messages. See the Troubleshooting
308 section if the script is not able to detect the power source correctly.
309 </p>
310
311 <p>
312 Due to the nature of the event mechanism, your laptop will boot into runlevel
313 <e>default</e> regardless of the AC/battery state. You can add another entry
314 to the boot loader with <c>softlevel=battery</c>, but it's likely to forget
315 choosing it. A better way is faking an ACPI event in the end of the boot
316 process and let the <path>/etc/acpi/default.sh</path> script decide whether a
317 runlevel change is necessary. Open <path>/etc/conf.d/local.start</path> in your
318 favourite editor and add these lines:
319 </p>
320
321 <pre caption="Runlevel switch at boot time by editing local.start">
322 <comment># Fake acpi event to switch runlevel if running on batteries</comment>
323 /etc/acpi/actions/pmg_switch_runlevel.sh "battery/battery"
324 </pre>
325
326 <p>
327 Prepared like this you can activate Power Management policies for individual
328 devices.
329 </p>
330
331 </body>
332 </section>
333 </chapter>
334
335 <chapter>
336 <title>CPU Power Management</title>
337 <section>
338 <title>Some technical terms</title>
339 <body>
340
341 <p>
342 CPU frequency scaling brings up some technical terms that might be unknown to
343 you. Here's a quick introduction.
344 </p>
345
346 <p>
347 First of all, the kernel has to be able to change the processor's frequency. The
348 <e>CPUfreq processor driver</e> knows the commands to do it on your CPU. Thus
349 it's important to choose the right one in your kernel. You should already have
350 done it above. Once the kernel knows how to change frequencies, it has to know
351 which frequency it should set. This is done according to the <e>policy</e> which
352 consists of a <e>CPUfreq policy</e> and a <e>governor</e>. A CPUfreq policy are
353 just two numbers which define a range the frequency has to stay between -
354 minimal and maximal frequency. The governor now decides which of the available
355 frequencies in between minimal and maximal frequency to choose. For example, the
356 <e>powersave governor</e> always chooses the lowest frequency available, the
357 <e>performance governor</e> the highest one. The <e>userspace governor</e> makes
358 no decision but chooses whatever the user (or a program in userspace) wants -
359 which means it reads the frequency from
360 <path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path>.
361 </p>
362
363 <p>
364 This doesn't sound like dynamic frequency changes yet and in fact it isn't.
365 Dynamics however can be accomplished with various approaches. For example,
366 the <e>ondemand governor</e> makes its decisions depending on the current CPU
367 load. The same is done by various userland tools like <c>cpudyn</c>,
368 <c>cpufreqd</c>, <c>powernowd</c> and many more. ACPI events can be used to
369 enable or disable dynamic frequency changes depending on power source.
370 </p>
371
372 </body>
373 </section>
374 <section>
375 <title>Setting the frequency manually</title>
376 <body>
377
378 <p>
379 Decreasing CPU speed and voltage has two advantages: On the one hand less
380 energy is consumed, on the other hand there is thermal improvement as your
381 system doesn't get as hot as running on full speed. The main disadvantage is
382 obviously the loss of performance. Decreasing processor speed is a trade off
383 between performance loss and energy saving.
384 </p>
385
386 <note>
387 Not every laptop supports frequency scaling. If unsure, have a look at the list
388 of supported processors in the <e>Troubleshooting</e> section to verify your's
389 is supported.
390 </note>
391
392 <p>
393 It's time to test whether CPU frequency changing works. Let's install another
394 tool which is very handy for debugging purposes: <c>sys-power/cpufrequtils</c>
395 </p>
396
397 <pre caption="Checking CPU frequency">
398 # <i>emerge cpufrequtils</i>
399 # <i>cpufreq-info</i>
400 </pre>
401
402 <p>
403 Here is an example output:
404 </p>
405
406 <pre caption="Sample output from cpufreq-info">
407 cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004
408 Report errors and bugs to linux@brodo.de, please.
409 analyzing CPU 0:
410 driver: centrino
411 CPUs which need to switch frequency at the same time: 0
412 hardware limits: 600 MHz - 1.40 GHz
413 available frequency steps: 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz
414 available cpufreq governors: ondemand, powersave, userspace, performance
415 current policy: frequency should be within 924 MHz and 1.40 GHz.
416 The governor "performance" may decide which speed to use
417 within this range.
418 current CPU frequency is 1.40 GHz (asserted by call to hardware).
419 </pre>
420
421 <p>
422 Now play around with <c>cpufreq-set</c> to make sure frequency switching works.
423 Run <c>cpufreq-set -g ondemand</c> for example to activate the ondemand
424 governor and verify the change with <c>cpufreq-info</c>. If it doesn't work as
425 expected, you might find help in the Troubleshooting section in the end of this
426 guide.
427 </p>
428
429 </body>
430 </section>
431 <section>
432 <title>Automated frequency adaption</title>
433 <body>
434
435 <p>
436 The above is quite nice, but not doable in daily life. Better let your system
437 set the appropriate frequency automatically. There are many different approaches
438 to do this. The following table gives a quick overview to help you decide on one
439 of them. It's roughly seperated in three categories <e>kernel</e> for approaches
440 that only need kernel support, <e>daemon</e> for programs that run in the
441 background and <e>graphical</e> for programs that provide a GUI for easy
442 configuration and changes.
443 </p>
444
445 <table>
446 <tr>
447 <th>Name</th>
448 <th>Category</th>
449 <th>Switch decision</th>
450 <th>Kernel governors</th>
451 <th>Further governors</th>
452 <th>Comments</th>
453 </tr>
454 <tr>
455 <ti>'ondemand' governor</ti>
456 <ti>Kernel</ti>
457 <ti>CPU load</ti>
458 <ti>N.A.</ti>
459 <ti>N.A.</ti>
460 <ti>
461 Further tuning through files in
462 <path>/sys/devices/system/cpu/cpu0/cpufreq/ondemand/</path>. Still requires
463 userland tools (programs, scripts) if governor switching or similar is
464 desired.
465 </ti>
466 </tr>
467 <tr>
468 <ti><uri link="http://mnm.uib.es/~gallir/cpudyn/">cpudyn</uri></ti>
469 <ti>Daemon</ti>
470 <ti>CPU load</ti>
471 <ti>Performance, powersave</ti>
472 <ti>Dynamic</ti>
473 <ti>
474 Also supports disk standby - notice however that <e>laptop mode</e> in most
475 cases will do a better job.
476 </ti>
477 </tr>
478 <tr>
479 <ti><uri link="http://sourceforge.net/projects/cpufreqd/">cpufreqd</uri></ti>
480 <ti>Daemon</ti>
481 <ti>Battery state, CPU load, running programs</ti>
482 <ti>All available</ti>
483 <ti>None</ti>
484 <ti>
485 Sophisticated (but also complicated) setup.
486 </ti>
487 </tr>
488 <tr>
489 <ti>
490 <uri link="http://www.deater.net/john/powernowd.html">powernowd</uri>
491 </ti>
492 <ti>Daemon</ti>
493 <ti>CPU load</ti>
494 <ti>None</ti>
495 <ti>Passive, sine, aggressive</ti>
496 <ti>
497 Supports SMP.
498 </ti>
499 </tr>
500 <tr>
501 <ti><uri link="http://www.goop.org/~jeremy/speedfreq/">speedfreq</uri></ti>
502 <ti>Daemon</ti>
503 <ti>CPU load</ti>
504 <ti>None</ti>
505 <ti>Dynamic, powersave, performance, fixed speed</ti>
506 <ti>
507 Small yet powerful with an useful client/server interface. Requires a 2.6
508 kernel. Doesn't seem to be maintained anymore and will be removed from
509 Portage in the near future.
510 </ti>
511 </tr>
512 <tr>
513 <ti><uri link="http://cpuspeedy.sourceforge.net/">gtk-cpuspeedy</uri></ti>
514 <ti>Graphical</ti>
515 <ti>None</ti>
516 <ti>None</ti>
517 <ti>None</ti>
518 <ti>
519 Gnome application, a graphical tool to set CPU frequency manually. It does
520 not offer any automation.
521 </ti>
522 </tr>
523 <tr>
524 <ti>klaptopdaemon</ti>
525 <ti>Graphical</ti>
526 <ti>Battery state</ti>
527 <ti>All available</ti>
528 <ti>None</ti>
529 <ti>
530 KDE only, 'ondemand' governor required for dynamic frequency scaling.
531 </ti>
532 </tr>
533 </table>
534
535 <p>
536 While adjusting the frequency to the current load looks simple on the first
537 view, it's not such a trivial task. A bad algorithm can cause switching between
538 two frequencies all the time or wasting energy when setting frequency to an
539 unnecessary high level.
540 </p>
541
542 <p>
543 Which one to choose? If you have no idea about it, try <c>cpufreqd</c>:
544 </p>
545
546 <pre caption="Installing cpufreqd">
547 # <i>emerge cpufreqd</i>
548 </pre>
549
550 <p>
551 <c>cpufreqd</c> can be configured by editing <path>/etc/cpufreqd.conf</path>.
552 The default one that ships with cpufreqd may look a bit confusing. I recommend
553 replacing it with the one from Gentoo developer Henrik Brix Andersen (see
554 below).
555 </p>
556
557 <pre caption="/etc/cpufreqd.conf">
558 [General]
559 pidfile=/var/run/cpufreqd.pid
560 poll_interval=2
561 pm_type=acpi
562 verbosity=5
563
564 [Profile]
565 name=ondemand
566 minfreq=0%
567 maxfreq=100%
568 policy=ondemand
569
570 [Profile]
571 name=powersave
572 minfreq=0%
573 maxfreq=100%
574 policy=powersave
575
576 [Profile]
577 name=performance
578 minfreq=0%
579 maxfreq=100%
580 policy=performance
581
582 [Rule]
583 name=battery
584 ac=off
585 profile=ondemand
586
587 [Rule]
588 name=battery_low
589 ac=off
590 battery_interval=0-10
591 profile=powersave
592
593 [Rule]
594 name=ac
595 ac=on
596 profile=performance
597 </pre>
598
599 <p>
600 You can't use a percentage value like above for min_freq and max_freq if you
601 are using kernel 2.6 with the sysfs interface (you probably do). Replace it
602 with the lowest and highest frequency as reported by <c>cpufreq-info
603 --hwlimits</c>. For example, on my 1.4 GHz Pentium M I put in
604 </p>
605
606 <pre caption="Sample values for minfreq and maxfreq">
607 minfreq=600000
608 maxfreq=1400000
609 </pre>
610
611 <p>
612 Last not least start the daemon.
613 </p>
614
615 <pre caption="Starting cpufreqd">
616 # <i>rc-update add cpufreqd default battery</i>
617 # <i>rc</i>
618 </pre>
619
620 <warn>
621 Do not run more than one of the above programs at the same time. It may cause
622 confusion like switching between two frequencies all the time.
623 </warn>
624
625 </body>
626 </section>
627
628 <section>
629 <title>Verifying the result</title>
630
631 <body>
632
633 <p>
634 The last thing to check is that your new policies do a good job. An easy way to
635 do so is monitoring CPU speed while working with your laptop:
636 </p>
637
638 <pre caption="Monitoring CPU speed">
639 # <i>watch grep "cpu MHz" /proc/cpuinfo</i>
640 </pre>
641
642 <p>
643 If <path>/proc/cpuinfo</path> doesn't get updated (see Troubleshooting),
644 monitor the CPU frequency with:
645 </p>
646
647 <pre caption="Alternative CPU speed monitoring">
648 # <i>watch x86info -mhz</i>
649 </pre>
650
651 <p>
652 Depending on your setup, CPU speed should increase on heavy load, decrease on
653 no activity or just stay at the same level. When using cpufreqd and verbosity
654 set to 5 or higher in <path>cpufreqd.conf</path> you'll get additional
655 information about what's happening reported to syslog.
656 </p>
657
658 </body>
659 </section>
660 </chapter>
661
662 <chapter>
663 <title>LCD Power Management</title>
664 <section>
665 <title>Energy consumer no. 1</title>
666 <body>
667
668 <p>
669 As you can see in <uri link="#doc_chap1_fig1">figure 1.1</uri>, the LCD display
670 consumes the biggest part of energy (might not be the case for non-mobile
671 CPU's). Thus it's quite important not only to shut the display off when not
672 needed, but also to reduce it's backlight if possible. Most laptops offer the
673 possibility to control the backlight dimming.
674 </p>
675
676 <p>
677 First thing to check is the standby/suspend/off timings of the display. As this
678 depends heavily on your windowmanager, I'll let you figure it out yourself.
679 Just two common places: Blanking the terminal can be done with <c>setterm
680 -blank &lt;number-of-minutesM&gt;</c>, <c>setterm -powersave on</c> and
681 <c>setterm -powerdown &lt;number-of-minutesM&gt;</c>.
682 For Xorg, modify <path>/etc/X11/xorg.conf</path> similar to this:
683 </p>
684
685 <pre caption="LCD suspend settings in Xorg and XFree86">
686 Section "ServerLayout"
687 Identifier [...]
688 [...]
689 Option "BlankTime" "5" <comment># Blank the screen after 5 minutes (Fake)</comment>
690 Option "StandbyTime" "10" <comment># Turn off screen after 10 minutes (DPMS)</comment>
691 Option "SuspendTime" "20" <comment># Full suspend after 20 minutes</comment>
692 Option "OffTime" "30" <comment># Turn off after half an hour</comment>
693 [...]
694 EndSection
695
696 [...]
697
698 Section "Monitor"
699 Identifier [...]
700 Option "DPMS" "true"
701 [...]
702 EndSection
703 </pre>
704
705 <p>
706 This is the same for XFree86 and <path>/etc/X11/XF86Config</path>.
707 </p>
708
709 <p>
710 Probably more important is the backlight dimming. If you have access to the
711 dimming settings via a tool, write a small script that dims the backlight in
712 battery mode and place it in your <e>battery</e> runlevel. The following script
713 should work on most IBM Thinkpads. It needs the <c>app-laptop/ibm-acpi</c>
714 package or the appropriate option in your kernel has to be enabled.
715 </p>
716
717 <warn>
718 Support for setting brightness is marked experimental in ibm-acpi. It accesses
719 hardware directly and may cause severe harm to your system. Please read the
720 <uri link="http://ibm-acpi.sourceforge.net/">ibm-acpi website</uri>
721 </warn>
722
723 <p>
724 To be able to set the brightness level, the ibm_acpi module has to be loaded
725 with the experimental parameter.
726 </p>
727
728 <pre caption="automatically loading the ibm_acpi module">
729 <comment>(Please read the warnings above before doing this!)</comment>
730 <i># emerge ibm-acpi</i>
731 <i># echo "options ibm_acpi experimental=1" >> /etc/modules.d/ibm_acpi</i>
732 <i># /sbin/modules-update</i>
733 <i># echo ibm_acpi >> /etc/modules.autoload.d/kernel-2.6</i>
734 <i># modprobe ibm_acpi</i>
735 </pre>
736
737 <p>
738 This should work without error messages and a file
739 <path>/proc/acpi/ibm/brightness</path> should be created after loading the
740 module. An init script will take care of choosing the brightness according
741 to the power source.
742 </p>
743
744 <pre caption="/etc/conf.d/lcd-brightness">
745 <comment># See /proc/acpi/ibm/brightness for available values</comment>
746 <comment># Please read /usr/share/doc/ibm-acpi-*/README.gz</comment>
747
748 <comment># brigthness level in ac mode. Default is 7.</comment>
749 BRIGHTNESS_AC=7
750
751 <comment># brightness level in battery mode. Default is 4.</comment>
752 BRIGHTNESS_BATTERY=4
753 </pre>
754
755 <pre caption="/etc/init.d/lcd-brightness">
756 #!/sbin/runscript
757
758 set_brightness() {
759 if on_ac_power
760 then
761 LEVEL=${BRIGHTNESS_AC:-7}
762 else
763 LEVEL=${BRIGHTNESS_BATTERY:-4}
764 fi
765
766 if [ -f /proc/acpi/ibm/brightness ]
767 then
768 ebegin "Setting LCD brightness"
769 echo "level ${LEVEL}" > /proc/acpi/ibm/brightness
770 eend $?
771 else
772 ewarn "Setting LCD brightness is not supported."
773 ewarn "Check that ibm_acpi is loaded into the kernel"
774 fi
775 }
776
777 start() {
778 set_brightness
779 }
780
781 stop () {
782 set_brightness
783 }
784 </pre>
785
786 <p>
787 When done, make sure brightness is adjusted automatically by adding it to the
788 battery runlevel.
789 </p>
790
791 <pre caption="Enabling automatic brightness adjustment">
792 <i># chmod +x /etc/init.d/lcd-brightness</i>
793 <i># rc-update add lcd-brightness battery</i>
794 <i># rc</i>
795 </pre>
796
797 </body>
798 </section>
799 </chapter>
800
801 <chapter>
802 <title>Disk Power Management</title>
803 <section>
804 <title>Sleep when idle</title>
805 <body>
806
807 <p>
808 Let's bring the hard disk to sleep as early as possible whenever it is not
809 needed. I'll show you two possibilities to do it. First <c>cpudyn</c> supports
810 Disk Power Management. Uncomment the lines in the "Disk Options" section in
811 <path>/etc/conf.d/cpudyn</path>. To put your first disk to sleep after 60
812 seconds of no activity, you would modify it like this:
813 </p>
814
815 <pre caption="Using cpudyn for disk standby">
816 <comment>################################################
817 # DISK OPTIONS
818 # (disabled by default)
819 ################################################
820
821 #
822 # Timeout to put the disk in standby mode if there was no
823 # io during that period (in seconds)
824 #
825 </comment>
826 TIMEOUT=60
827 <comment>
828 #
829 # Specified disks to spindown (comma separated devices)
830 #
831 </comment>
832 DISKS=/dev/hda
833 </pre>
834
835 <p>
836 The second possibility is using a small script and hdparm. Create
837 <path>/etc/init.d/pm.hda</path> like this:
838 </p>
839
840 <pre caption="Using hdparm for disk standby">
841 #!/sbin/runscript
842
843 depend() {
844 after hdparm
845 }
846
847 start() {
848 ebegin "Activating Power Management for Hard Drives"
849 hdparm -q -S12 /dev/hda
850 eend $?
851 }
852
853 stop () {
854 ebegin "Deactivating Power Management for Hard Drives"
855 hdparm -q -S253 /dev/hda
856 eend $?
857 }
858 </pre>
859
860 <p>
861 See <c>man hdparm</c> for the options. If your script is ready, add it to the
862 battery runlevel.
863 </p>
864
865 <pre caption="Automate disk standby settings">
866 # <i>chmod +x /etc/init.d/pm.hda</i>
867 # <i>/sbin/depscan.sh</i>
868 # <i>rc-update add pm.hda battery</i>
869 </pre>
870
871 <impo>
872 Be careful with sleep/spin down settings of your hard drive. Setting it to
873 small values might wear out your drive and lose warranty.
874 </impo>
875
876 </body>
877 </section>
878 <section>
879 <title>Increasing idle time - laptop-mode</title>
880 <body>
881
882 <p>
883 Recent kernels (2.6.6 and greater, recent 2.4 ones and others with patches)
884 include the so-called <e>laptop-mode</e>. When activated, dirty buffers are
885 written to disk on read calls or after 10 minutes (instead of 30 seconds). This
886 minimizes the time the hard disk needs to be spun up.
887 </p>
888
889 <pre caption="Automated start of laptop-mode">
890 # <i>emerge laptop-mode-tools</i>
891 </pre>
892
893 <p>
894 <c>laptop-mode-tools</c> has it's configuration file in
895 <path>/etc/laptop-mode/laptop-mode.conf</path>. Adjust it the way you like it,
896 it's well commented. Run <c>rc-update add laptop_mode battery</c> to start it
897 automatically.
898 </p>
899
900 </body>
901 </section>
902 <section>
903 <title>Other tricks</title>
904 <body>
905
906 <p>
907 Besides putting your disk to sleep state as early as possible, it is a good
908 idea to minimize disk accesses. Have a look at processes that write to your
909 disk frequently - the syslogd is a good candidate. You probably don't want to
910 shut it down completely, but it's possible to modify the config file so that
911 "unnecessary" things don't get logged and thus don't create disk traffic. Cups
912 writes to disk periodically, so consider shutting it down and only enable it
913 manually when needed.
914 </p>
915
916 <pre caption="Disabling cups in battery mode">
917 # <i>rc-update del cupsd battery</i>
918 </pre>
919
920 <p>
921 Another possibility is to deactivate swap in battery mode. Before writing a
922 swapon/swapoff switcher, make sure there is enough RAM and swap isn't used
923 heavily, otherwise you'll be in big problems.
924 </p>
925
926 <p>
927 If you don't want to use laptop-mode, it's still possible to minimize disk
928 access by mounting certain directories as <e>tmpfs</e> - write accesses are not
929 stored on a disk, but in main memory and get lost with unmounting. Often it's
930 useful to mount <path>/tmp</path> like this - you don't have to pay special
931 attention as it gets cleared on every reboot regardless whether it was mounted
932 on disk or in RAM. Just make sure you have enough RAM and no program (like a
933 download client or compress utility) needs extraordinary much space in
934 <path>/tmp</path>. To activate this, enable tmpfs support in your kernel and
935 add a line to <path>/etc/fstab</path> like this:
936 </p>
937
938 <pre caption="Editing /etc/fstab to make /tmp even more volatile">
939 none /tmp tmpfs size=32m 0 0
940 </pre>
941
942 <warn>
943 Pay attention to the size parameter and modify it for your system. If you're
944 unsure, don't try this at all, it can become a perfomance bottleneck easily. In
945 case you want to mount <path>/var/log</path> like this, make sure to merge the
946 log files to disk before unmounting. They are essential. Don't attempt to mount
947 /var/tmp like this. Portage uses it for compiling...
948 </warn>
949
950 </body>
951 </section>
952 </chapter>
953
954 <chapter>
955 <title>Power Management for other devices</title>
956 <section>
957 <title>Wireless Power Management</title>
958 <body>
959
960 <p>
961 Wireless LAN cards consume quite a few energy. Put them in Power Management
962 mode in analogy to the pm.hda script.
963 </p>
964
965 <pre caption="WLAN Power Management automated">
966 #!/sbin/runscript
967 start() {
968 ebegin "Activating Power Management for Wireless LAN"
969 iwconfig wlan0 power on power max period 3
970 eend $?
971 }
972
973 stop () {
974 ebegin "Deactivating Power Management for Wireless LAN"
975 iwconfig wlan0 power off
976 eend $?
977 }
978 </pre>
979
980 <p>
981 Starting this script will put wlan0 in Power Management mode, going to sleep at
982 the latest three seconds after no traffic.
983 Save it as <path>/etc/init.d/pm.wlan0</path> and add it to the battery runlevel
984 like the disk script above. See <c>man iwconfig</c> for details and more
985 options. If your driver and access point support changing the beacon time, this
986 is a good starting point to save even more energy.
987 </p>
988
989 <pre caption="Power Management for WLAN">
990 # <i>chmod +x /etc/init.d/pm.wlan0</i>
991 # <i>/sbin/depscan.sh</i>
992 # <i>rc-update add pm.wlan0 battery</i>
993 </pre>
994
995 </body>
996 </section>
997 <section>
998 <title>USB Power Management</title>
999 <body>
1000
1001 <p>
1002 There are two problems with USB devices regarding energy consumption: First,
1003 devices like USB mice, digital cameras or USB sticks consume energy while
1004 plugged in. You cannot avoid this (nevertheless remove them in case they're not
1005 needed). Second, when there are USB devices plugged in, the USB host controller
1006 periodically accesses the bus which in turn prevents the CPU from going into
1007 C3/4 sleep mode. The OS answer to this problem is the so called "USB selective
1008 suspend", which has not yet been implemented in the kernel. USB selective
1009 suspend only allows bus accesses in case the device is in use. The cruel
1010 workaround until it's implemented is as following: Compile USB support and
1011 devices as modules and remove them via a script while they are not in use (e.g.
1012 when closing the lid).
1013 </p>
1014
1015 </body>
1016 </section>
1017 </chapter>
1018
1019 <chapter>
1020 <title>Sleep states: sleep, standby, suspend to disk</title>
1021 <section>
1022 <title>Overview</title>
1023 <body>
1024
1025 <p>
1026 ACPI defines different sleep states. The more important ones are
1027 </p>
1028
1029 <ul>
1030 <li>S1 aka Standby</li>
1031 <li>S3 aka Suspend to RAM aka Sleep</li>
1032 <li>S4 aka Suspend to Disk aka Hibernate</li>
1033 </ul>
1034
1035 <p>
1036 They can be called whenever the system is not in use, but a shutdown is not
1037 wanted due to the long boot time.
1038 </p>
1039
1040 </body>
1041 </section>
1042 <section>
1043 <title>Sleep, Standby &amp; Hibernate</title>
1044 <body>
1045
1046 <p>
1047 The ACPI support for these sleep states is marked as experimental for good
1048 reason. APM sleep states seem to be more stable, however you can't use APM and
1049 ACPI together.
1050 </p>
1051
1052 <warn>
1053 Altough sleep state support is improving much, it's still rather experimental.
1054 At last I got swsusp2 and suspend to RAM to work, but be warned: This will very
1055 likely not work but damage your data/system.
1056 </warn>
1057
1058 <p>
1059 There are currently three implementations for S4. The original one is swsusp,
1060 then there is swsusp2 which has the nicest interface (including bootsplash
1061 support), but requires manual kernel patching. Last not least we have
1062 Suspend-to-Disk, a fork of swsusp.
1063 </p>
1064
1065 <p>
1066 If this confused you, have a look at a <uri
1067 link="http://softwaresuspend.berlios.de/features.html#compare">feature
1068 comparison</uri>. If you still are confused and don't know which one to choose,
1069 first give swsusp2 a try, it looks most promising.
1070 </p>
1071
1072 <p>
1073 The kernel part for this is as following:
1074 </p>
1075
1076 <pre caption="Kernel configuration for the various suspend types">
1077 Power Management Options ---&gt;
1078
1079 <comment>(sleep and standby)</comment>
1080 ACPI( Advanced Configuration and Power Interface ) Support --->
1081 [*] ACPI Support
1082 [*] Sleep States
1083
1084 <comment>(hibernate with swsusp)</comment>
1085 [*] Software Suspend (EXPERIMENTAL)
1086
1087 <comment>(hibernate with swsusp2)</comment>
1088 Software Suspend 2
1089 --- Image Storage (you need at least one writer)
1090 [*] Swap Writer
1091 --- Page Transformers
1092 [*] LZF image compression
1093 (/dev/"your-swap-here") Default resume device name
1094
1095 <comment>(hibernate with Suspend-to-Disk)</comment>
1096 [*] Suspend-to-Disk Suport
1097 (/dev/"your-swap-here") Default resume partition
1098 </pre>
1099
1100 <p>
1101 Compile your kernel with the appropriate options enabled and issue <c>cat
1102 /proc/acpi/sleep</c> for 2.4 series respectively <c>cat /sys/power/state</c>
1103 for 2.6 to find out what is supported. The latter gives me <c>standby mem
1104 disk</c>. For swsusp, the kernel parameter <c>resume=/dev/"your-swap-here"</c>
1105 has to be appended. If booting is not possible due to a broken image, use
1106 <c>noresume</c> for swsusp, <c>pmdisk=off</c> for Suspend-to-Disk and
1107 <c>noresume2</c> for swsusp2.
1108 </p>
1109
1110 <p>
1111 To put your system in one of the sleep states, use
1112 </p>
1113
1114 <pre caption="Activating sleep states">
1115 <comment>(kernel 2.4 series)</comment>
1116 # <i>echo 1 &gt; /proc/acpi/sleep</i> <comment>(standby)</comment>
1117 # <i>echo 3 &gt; /proc/acpi/sleep</i> <comment>(sleep)</comment>
1118
1119 <comment>(kernel 2.6 series)</comment>
1120 # <i>echo -n standby &gt; /sys/power/state</i> <comment>(standby)</comment>
1121 # <i>echo -n mem &gt; /sys/power/state</i> <comment>(sleep)</comment>
1122
1123 <comment>(swsusp)</comment>
1124 # <i>echo 4 &gt; /proc/acpi/sleep</i> <comment>(hibernate)</comment>
1125
1126 <comment>(Suspend-to-Disk)</comment>
1127 # <i>echo -n disk &gt; /sys/power/state</i> <comment>(hibernate)</comment>
1128
1129 <comment>(swsusp2)</comment>
1130 # <i>/usr/sbin/hibernate</i> <comment>(hibernate, see below)</comment>
1131 </pre>
1132
1133 <warn>
1134 Backup your data before doing this. Run <c>sync</c> before executing one of the
1135 commands to have cached data written to disk. First try it outside of X, then
1136 with X running, but not logged in.
1137 </warn>
1138
1139 <p>
1140 If you experience kernel panics due to uhci or similar, try to compile USB
1141 support as module and unload the modules before sending your laptop to sleep
1142 mode.
1143 </p>
1144
1145 <p>
1146 While the above should be sufficient to get swsusp and Suspend-to-Disk running
1147 (I didn't say working), swsusp2 needs special care.
1148 The first thing to do is patching the kernel with the patches provided at <uri
1149 link="http://softwaresuspend.berlios.de/">
1150 http://softwaresuspend.berlios.de/</uri>. Additionally you've got to emerge
1151 <c>hibernate-script</c>. Once it is installed, configure
1152 <path>/etc/hibernate/hibernate.conf</path> and try whether it works:
1153 </p>
1154
1155 <pre>
1156 <i># emerge hibernate-script</i>
1157 <i># $EDITOR /etc/hibernate/hibernate.conf</i>
1158 <comment>(Last chance to backup any data)</comment>
1159 <i># hibernate</i>
1160 </pre>
1161
1162 </body>
1163 </section>
1164 </chapter>
1165
1166 <chapter>
1167 <title>Troubleshooting</title>
1168 <section>
1169 <title>If things go wrong...</title>
1170 <body>
1171
1172 <p>
1173 <e>Q:</e> I'm trying to change the CPU frequency, but
1174 <path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor</path> does not
1175 exist.
1176 </p>
1177
1178 <p>
1179 <e>A:</e> Make sure your processor supports CPU frequency scaling and you chose
1180 the right CPUFreq driver for your processor. Here is a list of processors that
1181 are supported by cpufreq (kernel 2.6.7): ARM Integrator, ARM-SA1100,
1182 ARM-SA1110, AMD Elan - SC400, SC410, AMD mobile K6-2+, AMD mobile K6-3+, AMD
1183 mobile Duron, AMD mobile Athlon, AMD Opteron, AMD Athlon 64, Cyrix Media GXm,
1184 Intel mobile PIII and Intel mobile PIII-M on certain chipsets, Intel Pentium 4,
1185 Intel Xeon, Intel Pentium M (Centrino), National Semiconductors Geode GX,
1186 Transmeta Crusoe, VIA Cyrix 3 / C3, UltraSPARC-III, SuperH SH-3, SH-4, several
1187 "PowerBook" and "iBook2" and various processors on some ACPI 2.0-compatible
1188 systems (only if "ACPI Processor Performance States" are available to the
1189 ACPI/BIOS interface).
1190 </p>
1191
1192 <p>
1193 <e>Q:</e> My laptop supports frequency scaling, but
1194 <path>/sys/devices/system/cpu/cpu0/cpufreq/</path> is empty.
1195 </p>
1196
1197 <p>
1198 <e>A:</e> Look for ACPI related error messages with <c>dmesg | grep ACPI</c>.
1199 Try to update the BIOS, especially if a broken DSDT is reported. You can also
1200 try to fix it yourself (which is beyond the scope of this guide).
1201 </p>
1202
1203 <p>
1204 <e>Q:</e> My laptop supports frequency scaling, but according to /proc/cpuinfo
1205 the speed never changes.
1206 </p>
1207
1208 <p>
1209 <e>A:</e> Probably you have activated symmetric multiprocessing support
1210 (CONFIG_SMP) in your kernel. Deactivate it and it should work. Some older
1211 kernels had a bug causing this. In that case, run <c>emerge x86info</c>,
1212 update your kernel as asked and check the current frequency with
1213 <c>x86info -mhz</c>.
1214 </p>
1215
1216 <p>
1217 <e>Q:</e> I can change the CPU frequency, but the range is not as wide as in
1218 another OS.
1219 </p>
1220
1221 <p>
1222 <e>A:</e> You can combine frequency scaling with ACPI throttling to get a lower
1223 minimum frequency. Notice that throttling doesn't save much energy and is
1224 mainly used for thermal management (keeping your laptop cool and quiet). You
1225 can read the current throttling state with <c>cat
1226 /proc/acpi/processor/CPU/throttling</c> and change it with <c>echo -n "0:x" >
1227 /proc/acpi/processor/CPU/limit</c>, where x is one of the Tx states listed in
1228 <path>/proc/acpi/processor/CPU/throttling</path>.
1229 </p>
1230
1231 <p>
1232 <e>Q:</e> When configuring the kernel, powersave, performance and userspace
1233 governors show up, but that ondemand thing is missing. Where do I get it?
1234 </p>
1235
1236 <p>
1237 <e>A:</e> The ondemand governor is only included in recent kernel sources. Try
1238 updating them.
1239 </p>
1240
1241 <p>
1242 <e>Q:</e> Battery life time seems to be worse than before.
1243 </p>
1244
1245 <p>
1246 <e>A:</e> Check your BIOS settings. Maybe you forgot to re-enable some of the
1247 settings.
1248 </p>
1249
1250 <p>
1251 <e>Q:</e> My battery is charged, but KDE reports there would be 0% left and
1252 immediately shuts down.
1253 </p>
1254
1255 <p>
1256 <e>A:</e> Check that battery support is compiled into your kernel. If you use
1257 it as a module, make sure the module is loaded.
1258 </p>
1259
1260 <p>
1261 <e>Q:</e> I have a Dell Inspiron 51XX and I don't get any ACPI events.
1262 </p>
1263
1264 <p>
1265 <e>A:</e> This seems to be a kernel bug. Read on <uri
1266 link="http://bugme.osdl.org/show_bug.cgi?id=1752">here</uri>.
1267 </p>
1268
1269 <p>
1270 <e>Q:</e> I just bought a brand new battery, but it only lasts for some
1271 minutes! What am I doing wrong?
1272 </p>
1273
1274 <p>
1275 <e>A:</e> First follow your manufacturer's advice on how to charge the battery
1276 correctly.
1277 </p>
1278
1279 <p>
1280 <e>Q:</e> The above didn't help. What should I do then?
1281 </p>
1282
1283 <p>
1284 <e>A:</e> Some batteries sold as "new" are in fact old ones. Try the following:
1285 </p>
1286
1287 <pre caption="Querying battery state">
1288 $ <i>grep capacity /proc/acpi/battery/BAT0/info</i>
1289 design capacity: 47520 mWh
1290 last full capacity: 41830 mWh
1291 </pre>
1292
1293 <p>
1294 If the "last full capacity" differs significantly from the design capacity,
1295 your battery is probably broken. Try to claim your warranty.
1296 </p>
1297
1298 <p>
1299 <e>Q:</e> My problem is not listed above. Where should I go next?
1300 </p>
1301
1302 <p>
1303 <e>A:</e> Don't fear to contact me, <mail link="fragfred@gmx.de">Dennis
1304 Nienhüser</mail>, directly.
1305 </p>
1306
1307 </body>
1308 </section>
1309 </chapter>
1310 </guide>

  ViewVC Help
Powered by ViewVC 1.1.20