/[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.1 - (hide annotations) (download) (as text)
Sun Aug 29 11:26:34 2004 UTC (10 years ago) by swift
Branch: MAIN
File MIME type: application/xml
Adding power management guide to the doc repo

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

  ViewVC Help
Powered by ViewVC 1.1.20