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

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

Parent Directory Parent Directory | Revision Log Revision Log


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

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

  ViewVC Help
Powered by ViewVC 1.1.20