/[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.10 - (hide annotations) (download) (as text)
Sat Mar 19 16:48:25 2005 UTC (9 years, 9 months ago) by yoswink
Branch: MAIN
Changes since 1.9: +5 -5 lines
File MIME type: application/xml
Changes on sys-apps category due to #84238

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

  ViewVC Help
Powered by ViewVC 1.1.20