/[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.45 - (hide annotations) (download) (as text)
Wed Mar 2 09:18:04 2011 UTC (3 years, 8 months ago) by nightmorph
Branch: MAIN
Changes since 1.44: +3 -5 lines
File MIME type: application/xml
remove outdated keywording instructions now that tuxonice-userui is stable

1 swift 1.1 <?xml version='1.0' encoding="UTF-8"?>
2     <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3 nightmorph 1.45 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/power-management-guide.xml,v 1.44 2010/07/18 06:36:58 jkt Exp $ -->
4 nightmorph 1.42
5     <guide>
6 swift 1.1 <title>Power Management Guide</title>
7    
8 swift 1.4 <author title="Author">
9 nightmorph 1.17 <mail link="earthwings@gentoo.org">Dennis Nienhüser</mail>
10 swift 1.1 </author>
11 rane 1.19 <author title="Editor">
12     <mail link="chriswhite@gentoo.org">Chris White</mail>
13     </author>
14 nightmorph 1.26 <author title="Editor">
15 nightmorph 1.42 <mail link="nightmorph"/>
16 nightmorph 1.26 </author>
17 swift 1.1
18     <abstract>
19     Power Management is the key to extend battery run time on mobile systems like
20     laptops. This guide assists you setting it up on your laptop.
21     </abstract>
22    
23     <!-- The content of this document is licensed under the CC-BY-SA license -->
24 so 1.15 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
25 swift 1.1 <license/>
26    
27 nightmorph 1.45 <version>2</version>
28     <date>2011-03-02</date>
29 swift 1.1
30     <chapter>
31     <title>Introduction</title>
32     <section>
33     <body>
34    
35     <p>
36 so 1.15 Capacity and lifetime of laptop batteries have improved much in the last years.
37 swift 1.1 Nevertheless modern processors consume much more energy than older ones and
38     each laptop generation introduces more devices hungry for energy. That's why
39     Power Management is more important than ever. Increasing battery run time
40     doesn't necessarily mean buying another battery. Much can be achieved applying
41     intelligent Power Management policies.
42     </p>
43    
44     </body>
45     </section>
46     <section>
47 rane 1.19 <title>A Quick Overview</title>
48 swift 1.1 <body>
49    
50     <p>
51     Please notice that this guide describes Power Management for <e>laptops</e>.
52     While some sections might also suite for <e>servers</e>, others do not and may
53     even cause harm. Please do not apply anything from this guide to a server
54     unless you really know what you are doing.
55     </p>
56    
57     <p>
58     As this guide has become rather long, here's a short overview helping you to
59     find your way through it.
60     </p>
61    
62     <p>
63 rane 1.19 The <uri link="#doc_chap2">Prerequisites</uri> chapter talks about some
64     requirements that should be met before any of the following device individual
65     sections will work. This includes BIOS settings, kernel configuration and some
66     simplifications in user land. The following three chapters focus on devices
67     that typically consume most energy - processor, display and hard drive. Each
68     can be configured seperately. <uri link="#doc_chap3">CPU Power Management</uri>
69     shows how to adjust the processor's frequency to save a maximum of energy
70 rane 1.21 without losing too much performance. A few different tricks prevent your hard
71 rane 1.19 drive from working unnecessarily often in <uri link="#doc_chap5">Disk Power
72     Management</uri> (decreasing noise level as a nice side effect). Some notes on
73 rane 1.20 graphics cards, Wireless LAN and USB finish the device section in <uri
74     link="#doc_chap6">Power Management For Other Devices</uri> while another
75 rane 1.19 chapter is dedicated to the (rather experimental) <uri link="#doc_chap7">sleep
76 rane 1.20 states</uri>. Last not least <uri link="#doc_chap8">Troubleshooting</uri> lists
77     common pitfalls.
78 swift 1.1 </p>
79    
80     </body>
81     </section>
82     <section>
83 rane 1.19 <title>Power Budget For Each Component</title>
84 swift 1.1 <body>
85    
86 swift 1.2 <figure link="/images/energy-budget.png" short="Which component consumes how
87 swift 1.1 much energy?" caption="Power budget for each component"/>
88    
89     <p>
90     Nearly every component can operate in different states - off, sleep, idle,
91     active to name a few - consuming a different amount of energy. Major parts are
92     consumed by the LCD display, CPU, chipset and hard drives. Often one is able to
93     activate OS-independent Power Management in the BIOS, but an intelligent setup
94     in the operating system adapting to different situations can achieve much more.
95     </p>
96    
97     </body>
98     </section>
99     </chapter>
100    
101     <chapter>
102     <title>Prerequisites</title>
103     <section>
104     <body>
105    
106     <p>
107 nightmorph 1.17 Before discussing the details of making individual devices Power Management
108 rane 1.20 aware, make sure certain requirements are met. After controlling BIOS settings,
109     some kernel options want to be enabled - these are in short ACPI, sleep states
110     and CPU frequency scaling. As power saving most of the time comes along with
111     performance loss or increased latency, it should only be enabled when running
112     on batteries. That's where a new runlevel <e>battery</e> comes in handy.
113 swift 1.1 </p>
114    
115     </body>
116     </section>
117     <section>
118 rane 1.19 <title>The BIOS Part</title>
119 swift 1.1 <body>
120    
121     <p>
122     First have a look into your BIOS Power Management settings. The best way is to
123     combine BIOS and operating system policies, but for the moment it's better to
124     disable most of the BIOS part. This makes sure it doesn't interfere with your
125     policies. Don't forget to re-check BIOS settings after you configured
126     everything else.
127     </p>
128    
129     </body>
130     </section>
131     <section>
132 rane 1.19 <title>Setting USE Flags</title>
133 nightmorph 1.17 <body>
134    
135     <p>
136     Please check that the <c>acpi</c> USE flag is set in
137     <path>/etc/make.conf</path>. Other USE flags that might be interesting for your
138     system are <c>apm</c>, <c>lm_sensors</c>, <c>nforce2</c>, <c>nvidia</c>,
139     <c>pmu</c>. See <path>/usr/portage/profiles/use*.desc</path> for details. If
140     you forgot to set one of these flags, you can recompile affected packages using
141 rane 1.19 the <c>--newuse</c> flag in <c>emerge</c>, see <c>man emerge</c>.
142 nightmorph 1.17 </p>
143    
144     </body>
145     </section>
146     <section>
147 rane 1.19 <title>Configuring The Kernel</title>
148 swift 1.1 <body>
149    
150     <p>
151     ACPI (Advanced Configuration and Power Interface) support in the kernel is
152     still work in progress. Using a recent kernel will make sure you'll get the
153     most out of it.
154     </p>
155    
156     <p>
157 rane 1.20 There are different kernel sources in Portage. I'd recommend using
158 jkt 1.33 <c>gentoo-sources</c> or <c>tuxonice-sources</c>. The latter contains patches
159 jkt 1.34 for TuxOnIce, see the chapter about <uri link="#doc_chap7">sleep states</uri>
160     for more details. When configuring the kernel, activate at least these options:
161 swift 1.1 </p>
162    
163     <pre caption="Minimum kernel setup for Power Management (Kernel 2.6)">
164 nightmorph 1.39 Power management and ACPI options ---&gt;
165 nightmorph 1.40 [*] Power Management support
166 swift 1.1 [ ] Software Suspend
167    
168     ACPI( Advanced Configuration and Power Interface ) Support ---&gt;
169 nightmorph 1.39 [ ] Deprecated /proc/acpi/ files
170 neysx 1.12 [*] AC Adapter
171     [*] Battery
172 swift 1.1 &lt;M&gt; Button
173 so 1.15 &lt;M&gt; Video
174     [ ] Generic Hotkey
175 swift 1.1 &lt;M&gt; Fan
176     &lt;M&gt; Processor
177     &lt;M&gt; Thermal Zone
178     &lt; &gt; ASUS/Medion Laptop Extras
179 so 1.15 &lt; &gt; IBM ThinkPad Laptop Extras
180 swift 1.1 &lt; &gt; Toshiba Laptop Extras
181 so 1.15 (0) Disable ACPI for systems before Jan 1st this year
182 swift 1.1 [ ] Debug Statements
183 so 1.15 [*] Power Management Timer Support
184     &lt; &gt; ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)
185 rane 1.20
186 swift 1.1 CPU Frequency Scaling ---&gt;
187     [*] CPU Frequency scaling
188 so 1.15 [ ] Enable CPUfreq debugging
189     &lt; &gt; CPU frequency translation statistics
190     [ ] CPU frequency translation statistics details
191 swift 1.1 Default CPUFreq governor (userspace)
192     &lt;*&gt; 'performance' governor
193     &lt;*&gt; 'powersave' governor
194 swift 1.8 &lt;*&gt; 'ondemand' cpufreq policy governor
195 so 1.15 &lt;*&gt; 'conservative' cpufreq governor
196 swift 1.1 &lt;*&gt; CPU frequency table helpers
197     &lt;M&gt; ACPI Processor P-States driver
198     &lt;*&gt; <i>CPUFreq driver for your processor</i>
199     </pre>
200    
201     <p>
202 so 1.15 Decide yourself whether you want to enable Software Suspend, and Sleep States
203     (see below). If you own an ASUS, Medion, IBM Thinkpad or Toshiba laptop, enable
204 neysx 1.12 the appropriate section.
205 swift 1.8 </p>
206    
207     <p>
208 rane 1.20 The kernel has to know how to enable CPU frequency scaling on your processor.
209     As each type of CPU has a different interface, you've got to choose the right
210 rane 1.19 driver for your processor. Be careful here - enabling <c>Intel Pentium 4 clock
211     modulation</c> on a Pentium M system will lead to strange results for example.
212 swift 1.8 Consult the kernel documentation if you're unsure which one to take.
213 swift 1.1 </p>
214    
215     <p>
216     Compile your kernel, make sure the right modules get loaded at startup and boot
217 rane 1.20 into your new ACPI-enabled kernel. Next run <c>emerge sys-power/acpid</c> to
218     get the acpi daemon. This one informs you about events like switching from AC
219     to battery or closing the lid. Make sure the modules are loaded if you didn't
220     compile them into the kernel and start acpid by executing <c>/etc/init.d/acpid
221     start</c>. Run <c>rc-update add acpid default</c> to load it on startup. You'll
222     soon see how to use it.
223 swift 1.1 </p>
224    
225     <pre caption="Installing acpid">
226 yoswink 1.10 # <i>emerge sys-power/acpid</i>
227 swift 1.1 # <i>/etc/init.d/acpid start</i>
228     # <i>rc-update add acpid default</i>
229     </pre>
230    
231     </body>
232     </section>
233     <section>
234 rane 1.19 <title>Creating A "battery" Runlevel</title>
235 swift 1.1 <body>
236    
237     <p>
238     The default policy will be to enable Power Management only when needed -
239     running on batteries. To make the switch between AC and battery convenient,
240 rane 1.19 create a runlevel <c>battery</c> that holds all the scripts starting and
241 swift 1.1 stopping Power Management.
242     </p>
243    
244     <note>
245     You can safely skip this section if you don't like the idea of having another
246     runlevel. However, skipping this step will make the rest a bit trickier to set
247 rane 1.19 up. The next sections assume a runlevel <c>battery</c> exists.
248 swift 1.1 </note>
249    
250     <pre caption="Creating a battery runlevel">
251     # <i>cd /etc/runlevels</i>
252     # <i>cp -a default battery</i>
253     </pre>
254    
255     <p>
256 rane 1.19 Finished. Your new runlevel <c>battery</c> contains everything like
257     <c>default</c>, but there is no automatic switch between both yet. Time to
258 swift 1.1 change it.
259     </p>
260    
261     </body>
262     </section>
263     <section>
264 rane 1.19 <title>Reacting On ACPI Events</title>
265 swift 1.1 <body>
266    
267     <p>
268     Typical ACPI events are closing the lid, changing the power source or pressing
269 swift 1.8 the sleep button. An important event is changing the power source, which should
270 so 1.15 cause a runlevel switch. A small script will take care of it.
271     </p>
272    
273     <p>
274     First you need a script which changes the runlevel to <c>default</c>
275     respectively <c>battery</c> depending on the power source. The script uses the
276 nightmorph 1.43 <c>on_ac_power</c> command from <c>sys-power/pm-utils</c> - make sure the
277 so 1.15 package is installed on your system.
278     </p>
279    
280 nightmorph 1.43 <pre caption="Installing pm-utils">
281     # <i>emerge pm-utils</i>
282 so 1.15 </pre>
283    
284     <p>
285 rane 1.20 You are now able to determine the power source by executing <c>on_ac_power
286     &amp;&amp; echo AC available || echo Running on batteries</c> in a shell. The
287     script below is responsible for changing runlevels. Save it as
288 so 1.15 <path>/etc/acpi/actions/pmg_switch_runlevel.sh</path>.
289 swift 1.8 </p>
290    
291 neysx 1.12 <pre caption="/etc/acpi/actions/pmg_switch_runlevel.sh">
292 swift 1.8 #!/bin/bash
293    
294 neysx 1.12 <comment># BEGIN configuration</comment>
295 swift 1.8 RUNLEVEL_AC="default"
296     RUNLEVEL_BATTERY="battery"
297 neysx 1.12 <comment># END configuration</comment>
298 swift 1.8
299 swift 1.1
300 neysx 1.12 if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]
301     then
302 nightmorph 1.17 logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."
303     exit 1
304 neysx 1.12 fi
305 swift 1.8
306 neysx 1.12 if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]
307     then
308 nightmorph 1.17 logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."
309     exit 1
310 neysx 1.12 fi
311 swift 1.1
312 neysx 1.12 if on_ac_power
313     then
314 rane 1.19 if [[ "$(&lt;/var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
315 nightmorph 1.17 then
316     logger "Switching to ${RUNLEVEL_AC} runlevel"
317     /sbin/rc ${RUNLEVEL_AC}
318     fi
319 rane 1.19 elif [[ "$(&lt;/var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
320 neysx 1.12 then
321 nightmorph 1.17 logger "Switching to ${RUNLEVEL_BATTERY} runlevel"
322     /sbin/rc ${RUNLEVEL_BATTERY}
323 neysx 1.12 fi
324 swift 1.8 </pre>
325    
326 so 1.15 <p>
327     Dont forget to run <c>chmod +x /etc/acpi/actions/pmg_switch_runlevel.sh</c> to
328     make the script executable. The last thing that needs to be done is calling the
329     script whenever the power source changes. That's done by catching ACPI events
330     with the help of <c>acpid</c>. First you need to know which events are
331     generated when the power source changes. The events are called
332 rane 1.19 <c>ac_adapter</c> and <c>battery</c> on most laptops, but it might be different
333 so 1.15 on yours.
334     </p>
335    
336     <pre caption="Determining ACPI events for changing the power source">
337 nightmorph 1.42 # <i>tail -f /var/log/messages | grep "ACPI event"</i>
338 so 1.15 </pre>
339    
340     <p>
341 rane 1.20 Run the command above and pull the power cable. You should see something like
342     this:
343 so 1.15 </p>
344    
345     <pre caption="Sample output for power source changes">
346 nightmorph 1.42 [Tue Sep 20 17:39:06 2005] ACPI event "ac_adapter AC 00000080 00000000"
347     [Tue Sep 20 17:39:06 2005] ACPI event "battery BAT0 00000080 00000001"
348 so 1.15 </pre>
349    
350     <p>
351 jkt 1.44 The interesting part is the quoted string after <c>ACPI event</c>. It will
352 so 1.15 be matched by the event line in the files you are going to create below. Don't
353     worry if your system generates multiple events or always the same. As long as
354     any event is generated, runlevel changing will work.
355     </p>
356    
357 swift 1.8 <pre caption="/etc/acpi/events/pmg_ac_adapter">
358 neysx 1.12 <comment># replace "ac_adapter" below with the event generated on your laptop</comment>
359 so 1.15 <comment># For example, ac_adapter.* will match ac_adapter AC 00000080 00000000</comment>
360 swift 1.8 event=ac_adapter.*
361 neysx 1.12 action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
362 swift 1.8 </pre>
363    
364     <pre caption="/etc/acpi/events/pmg_battery">
365 neysx 1.12 <comment># replace "battery" below with the event generated on your laptop</comment>
366 so 1.15 <comment># For example, battery.* will match battery BAT0 00000080 00000001</comment>
367 swift 1.8 event=battery.*
368 neysx 1.12 action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
369 swift 1.8 </pre>
370 swift 1.1
371 swift 1.8 <p>
372 so 1.15 Finally acpid has to be restarted to recognize the changes.
373 swift 1.8 </p>
374 swift 1.1
375 swift 1.8 <pre caption="Finishing runlevel switching with acpid">
376 rane 1.19 # <i>/etc/init.d/acpid restart</i>
377 swift 1.1 </pre>
378    
379     <p>
380     Give it a try: Plug AC in and out and watch syslog for the "Switching to AC
381 rane 1.20 mode" or "Switching to battery mode" messages. See the <uri
382     link="#doc_chap8">Troubleshooting section</uri> if the script is not able to
383     detect the power source correctly.
384 swift 1.1 </p>
385    
386     <p>
387     Due to the nature of the event mechanism, your laptop will boot into runlevel
388 rane 1.19 <c>default</c> regardless of the AC/battery state. This is fine when running
389 rane 1.20 from AC, but we'd like to boot into the battery runlevel otherwise. One
390     solution would be to add another entry to the boot loader with the parameter
391 so 1.15 <c>softlevel=battery</c>, but it's likely to forget choosing it. A better way
392 rane 1.20 is faking an ACPI event in the end of the boot process and letting
393     <path>pmg_switch_runlevel.sh</path> script decide whether a runlevel change is
394     necessary. Open <path>/etc/conf.d/local.start</path> in your favourite editor
395     and add these lines:
396 swift 1.1 </p>
397    
398 so 1.15 <pre caption="Runlevel adjustment at boot time by editing local.start">
399 swift 1.1 <comment># Fake acpi event to switch runlevel if running on batteries</comment>
400 neysx 1.12 /etc/acpi/actions/pmg_switch_runlevel.sh "battery/battery"
401 swift 1.1 </pre>
402    
403     <p>
404 rane 1.20 Prepared like this you can activate Power Management policies for individual
405 swift 1.1 devices.
406     </p>
407    
408     </body>
409     </section>
410     </chapter>
411    
412     <chapter>
413     <title>CPU Power Management</title>
414     <section>
415 nightmorph 1.17 <body>
416    
417     <p>
418     Mobile processors can operate at different frequencies. Some allow changing
419     voltage as well. Most of the time your CPU doesn't need to run at full speed
420     and scaling it down will save much energy - often without any performance
421     decrease.
422     </p>
423    
424     </body>
425     </section>
426     <section>
427 rane 1.19 <title>Some Technical Terms</title>
428 swift 1.8 <body>
429    
430     <p>
431     CPU frequency scaling brings up some technical terms that might be unknown to
432     you. Here's a quick introduction.
433     </p>
434    
435     <p>
436 so 1.15 First of all, the kernel has to be able to change the processor's frequency.
437 rane 1.19 The <b>CPUfreq processor driver</b> knows the commands to do it on your CPU.
438 rane 1.20 Thus it's important to choose the right one in your kernel. You should already
439     have done it above. Once the kernel knows how to change frequencies, it has to
440     know which frequency it should set. This is done according to the <b>policy</b>
441     which consists of a <b>CPUfreq policy</b> and a <b>governor</b>. A CPUfreq
442     policy are just two numbers which define a range the frequency has to stay
443     between - minimal and maximal frequency. The governor now decides which of the
444     available frequencies in between minimal and maximal frequency to choose. For
445     example, the <b>powersave governor</b> always chooses the lowest frequency
446     available, the <b>performance governor</b> the highest one. The <b>userspace
447     governor</b> makes no decision but chooses whatever the user (or a program in
448     userspace) wants - which means it reads the frequency from
449 swift 1.8 <path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path>.
450     </p>
451    
452     <p>
453     This doesn't sound like dynamic frequency changes yet and in fact it isn't.
454 rane 1.20 Dynamics however can be accomplished with various approaches. For example, the
455     <b>ondemand governor</b> makes its decisions depending on the current CPU load.
456     The same is done by various userland tools like <c>cpudyn</c>, <c>cpufreqd</c>,
457     <c>powernowd</c> and many more. ACPI events can be used to enable or disable
458     dynamic frequency changes depending on power source.
459 swift 1.8 </p>
460    
461     </body>
462     </section>
463     <section>
464 nightmorph 1.41 <title>Setting The Frequency</title>
465 swift 1.1 <body>
466    
467     <p>
468     Decreasing CPU speed and voltage has two advantages: On the one hand less
469     energy is consumed, on the other hand there is thermal improvement as your
470     system doesn't get as hot as running on full speed. The main disadvantage is
471     obviously the loss of performance. Decreasing processor speed is a trade off
472     between performance loss and energy saving.
473     </p>
474    
475     <note>
476     Not every laptop supports frequency scaling. If unsure, have a look at the list
477 rane 1.19 of supported processors in the <uri link="#doc_chap8">Troubleshooting</uri>
478     section to verify yours is supported.
479 swift 1.1 </note>
480    
481     <p>
482 neysx 1.12 It's time to test whether CPU frequency changing works. Let's install another
483 nightmorph 1.41 tool: <c>sys-power/cpufrequtils</c>.
484 swift 1.1 </p>
485    
486 neysx 1.12 <pre caption="Checking CPU frequency">
487     # <i>emerge cpufrequtils</i>
488     # <i>cpufreq-info</i>
489 swift 1.1 </pre>
490    
491     <p>
492 neysx 1.12 Here is an example output:
493 swift 1.1 </p>
494    
495 neysx 1.12 <pre caption="Sample output from cpufreq-info">
496 so 1.15 cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004
497 neysx 1.12 Report errors and bugs to linux@brodo.de, please.
498     analyzing CPU 0:
499     driver: centrino
500     CPUs which need to switch frequency at the same time: 0
501     hardware limits: 600 MHz - 1.40 GHz
502     available frequency steps: 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz
503 so 1.15 available cpufreq governors: conservative, ondemand, powersave, userspace, performance
504 neysx 1.12 current policy: frequency should be within 924 MHz and 1.40 GHz.
505     The governor "performance" may decide which speed to use
506     within this range.
507 so 1.15 current CPU frequency is 1.40 GHz.
508 neysx 1.12 </pre>
509    
510 swift 1.1 <p>
511 neysx 1.12 Now play around with <c>cpufreq-set</c> to make sure frequency switching works.
512     Run <c>cpufreq-set -g ondemand</c> for example to activate the ondemand
513     governor and verify the change with <c>cpufreq-info</c>. If it doesn't work as
514 rane 1.20 expected, you might find help in the <uri link="#doc_chap8">Troubleshooting
515     section</uri> in the end of this guide.
516 swift 1.1 </p>
517    
518 nightmorph 1.41 <p>
519     <c>cpufrequtils</c> can operate in an automatic mode (when you use the
520     <b>ondemand</b> governor), you can also switch to the <b>userspace</b> governor
521     if you want to manually set a specific speed. You can also statically set your
522     CPU to its highest or lowest frequency by using the <b>performance</b>
523     and <b>powersave</b> governors, respectively.
524     </p>
525    
526     <pre caption="Changing CPU speeds">
527     <comment>(Set the highest available frequency)</comment>
528     # <i>cpufreq-set -g performance</i>
529     <comment>(Set the lowest available frequency)</comment>
530     # <i>cpufreq-set -g powersave</i>
531     <comment>(Set a specific frequency)</comment>
532     # <i>cpufreq-set -g userspace</i>
533     # <i>cpufreq-set -f 2.00ghz</i>
534     </pre>
535    
536 swift 1.1 </body>
537     </section>
538     <section>
539 nightmorph 1.41 <title>Other CPU Speed Utilities</title>
540 swift 1.1 <body>
541    
542     <p>
543 nightmorph 1.41 While <c>cpufrequtils</c> may be the best all-around program, there are some
544     other choices available in Portage. The following table gives a quick overview
545     of available CPU speed utilities. It's roughly separated in three categories
546     <b>kernel</b> for approaches that only need kernel support, <b>daemon</b> for
547     programs that run in the background and <b>graphical</b> for programs that
548     provide a GUI for easy configuration and changes.
549 swift 1.1 </p>
550    
551     <table>
552     <tr>
553     <th>Name</th>
554 swift 1.8 <th>Category</th>
555     <th>Switch decision</th>
556     <th>Kernel governors</th>
557     <th>Further governors</th>
558     <th>Comments</th>
559     </tr>
560     <tr>
561     <ti>'ondemand' governor</ti>
562     <ti>Kernel</ti>
563     <ti>CPU load</ti>
564     <ti>N.A.</ti>
565     <ti>N.A.</ti>
566     <ti>
567 so 1.15 Chooses maximal frequency on CPU load and slowly steps down when the CPU is
568     idle. Further tuning through files in
569 swift 1.8 <path>/sys/devices/system/cpu/cpu0/cpufreq/ondemand/</path>. Still requires
570     userland tools (programs, scripts) if governor switching or similar is
571     desired.
572     </ti>
573 swift 1.1 </tr>
574     <tr>
575 so 1.15 <ti>'conservative' governor</ti>
576     <ti>Kernel</ti>
577     <ti>CPU load</ti>
578     <ti>N.A.</ti>
579     <ti>N.A.</ti>
580     <ti>
581 neysx 1.16 Unlike the ondemand governor, conversative doesn't jump to maximum
582     frequency when CPU load is high, but increases the frequency step by step.
583     Further tuning through files in
584     <path>/sys/devices/system/cpu/cpu0/cpufreq/ondemand/</path>. Still requires
585     userland tools (programs, scripts) if governor switching or similar is
586     desired.
587 so 1.15 </ti>
588     </tr>
589     <tr>
590 swift 1.1 <ti><uri link="http://mnm.uib.es/~gallir/cpudyn/">cpudyn</uri></ti>
591 swift 1.8 <ti>Daemon</ti>
592     <ti>CPU load</ti>
593 neysx 1.12 <ti>Performance, powersave</ti>
594 swift 1.8 <ti>Dynamic</ti>
595     <ti>
596     Also supports disk standby - notice however that <e>laptop mode</e> in most
597     cases will do a better job.
598     </ti>
599 swift 1.1 </tr>
600     <tr>
601 swift 1.8 <ti><uri link="http://sourceforge.net/projects/cpufreqd/">cpufreqd</uri></ti>
602     <ti>Daemon</ti>
603 nightmorph 1.17 <ti>Battery state, CPU load, temperature, running programs and more</ti>
604 swift 1.8 <ti>All available</ti>
605     <ti>None</ti>
606     <ti>
607 nightmorph 1.17 Sophisticated (but somewhat complicated) setup. Extendible through plugins
608     like sensor monitoring (lm_sensors) or coordinating some NVidia based
609     graphics card memory and core. Cpufreqd is SMP aware and can optionally be
610     controlled manually at runtime.
611 swift 1.8 </ti>
612     </tr>
613     <tr>
614     <ti>
615     <uri link="http://www.deater.net/john/powernowd.html">powernowd</uri>
616     </ti>
617     <ti>Daemon</ti>
618     <ti>CPU load</ti>
619     <ti>None</ti>
620     <ti>Passive, sine, aggressive</ti>
621     <ti>
622     Supports SMP.
623     </ti>
624 swift 1.1 </tr>
625     <tr>
626 nightmorph 1.31 <ti>
627     <uri
628     link="http://projects.simpledesigns.com.pl/project/ncpufreqd/">ncpufreqd</uri>
629     </ti>
630 so 1.15 <ti>Daemon</ti>
631     <ti>Temperature</ti>
632     <ti>None</ti>
633     <ti>Powersave, performance</ti>
634     <ti>
635     Toggles the used governor between performance and powersave depending on
636     system temperature. Very useful on laptops with notorious heat problems.
637     </ti>
638     </tr>
639     <tr>
640 swift 1.1 <ti><uri link="http://www.goop.org/~jeremy/speedfreq/">speedfreq</uri></ti>
641 swift 1.8 <ti>Daemon</ti>
642     <ti>CPU load</ti>
643     <ti>None</ti>
644     <ti>Dynamic, powersave, performance, fixed speed</ti>
645     <ti>
646 so 1.15 Easy to configure with a nice client/server interface. Requires a 2.6
647     kernel. Unmaintained, broken and thus removed from Portage. Please switch
648     to cpufreqd if you're still using it.
649 swift 1.8 </ti>
650     </tr>
651     <tr>
652     <ti><uri link="http://cpuspeedy.sourceforge.net/">gtk-cpuspeedy</uri></ti>
653     <ti>Graphical</ti>
654     <ti>None</ti>
655     <ti>None</ti>
656     <ti>None</ti>
657 swift 1.1 <ti>
658 swift 1.8 Gnome application, a graphical tool to set CPU frequency manually. It does
659 neysx 1.12 not offer any automation.
660 swift 1.1 </ti>
661     </tr>
662     <tr>
663 swift 1.8 <ti>klaptopdaemon</ti>
664     <ti>Graphical</ti>
665     <ti>Battery state</ti>
666     <ti>All available</ti>
667     <ti>None</ti>
668     <ti>
669     KDE only, 'ondemand' governor required for dynamic frequency scaling.
670     </ti>
671 swift 1.1 </tr>
672     </table>
673    
674     <p>
675 so 1.15 While adjusting the frequency to the current load looks simple at a first
676     glance, it's not such a trivial task. A bad algorithm can cause switching
677     between two frequencies all the time or wasting energy when setting frequency
678 rane 1.20 to an unnecessary high level.
679 swift 1.1 </p>
680    
681     <p>
682 neysx 1.12 Which one to choose? If you have no idea about it, try <c>cpufreqd</c>:
683 swift 1.1 </p>
684    
685     <pre caption="Installing cpufreqd">
686     # <i>emerge cpufreqd</i>
687     </pre>
688    
689     <p>
690 neysx 1.12 <c>cpufreqd</c> can be configured by editing <path>/etc/cpufreqd.conf</path>.
691     The default one that ships with cpufreqd may look a bit confusing. I recommend
692 nightmorph 1.22 replacing it with the one from former Gentoo developer Henrik Brix Andersen
693     (see below). Please notice that you need cpufreqd-2.0.0 or later. Earlier
694     versions have a different syntax for the config file.
695 swift 1.1 </p>
696    
697 nightmorph 1.17 <pre caption="/etc/cpufreqd.conf (cpufreqd-2.0.0 and later)">
698 swift 1.1 [General]
699     pidfile=/var/run/cpufreqd.pid
700 nightmorph 1.17 poll_interval=3
701     enable_plugins=acpi_ac, acpi_battery
702 nightmorph 1.18 enable_remote=1
703     remote_group=wheel
704 neysx 1.12 verbosity=5
705 nightmorph 1.17 [/General]
706 swift 1.1
707     [Profile]
708 neysx 1.12 name=ondemand
709     minfreq=0%
710     maxfreq=100%
711     policy=ondemand
712 nightmorph 1.17 [/Profile]
713 swift 1.1
714     [Profile]
715 so 1.15 name=conservative
716     minfreq=0%
717     maxfreq=100%
718     policy=conservative
719 nightmorph 1.17 [/Profile]
720 so 1.15
721     [Profile]
722 neysx 1.12 name=powersave
723     minfreq=0%
724     maxfreq=100%
725 swift 1.1 policy=powersave
726 nightmorph 1.17 [/Profile]
727 swift 1.1
728     [Profile]
729 neysx 1.12 name=performance
730     minfreq=0%
731     maxfreq=100%
732     policy=performance
733 nightmorph 1.17 [/Profile]
734 swift 1.1
735     [Rule]
736 neysx 1.12 name=battery
737     ac=off
738 so 1.15 profile=conservative
739 nightmorph 1.17 [/Rule]
740 swift 1.1
741     [Rule]
742 neysx 1.12 name=battery_low
743 swift 1.1 ac=off
744 neysx 1.12 battery_interval=0-10
745     profile=powersave
746 nightmorph 1.17 [/Rule]
747 swift 1.1
748     [Rule]
749 neysx 1.12 name=ac
750     ac=on
751 so 1.15 profile=ondemand
752 nightmorph 1.17 [/Rule]
753 neysx 1.12 </pre>
754    
755     <p>
756 rane 1.19 Now you can start the cpufreqd daemon. Add it to the <c>default</c> and
757     <c>battery</c> runlevel as well.
758 swift 1.1 </p>
759    
760 neysx 1.12 <pre caption="Starting cpufreqd">
761     # <i>rc-update add cpufreqd default battery</i>
762 nightmorph 1.41 # <i>/etc/init.d/cpufreqd start</i>
763 neysx 1.12 </pre>
764    
765 nightmorph 1.17 <p>
766     Sometimes it can be desirable to select another policy than the daemon chooses,
767     for example when battery power is low, but you know that AC will be available
768 rane 1.20 soon. In that case you can turn on cpufreqd's manual mode with <c>cpufreqd-set
769     manual</c> and select one of your configured policies (as listed by
770     <c>cpufreqd-get</c>). You can leave manual mode by executing <c>cpufreqd-set
771     dynamic</c>.
772 nightmorph 1.17 </p>
773    
774 neysx 1.12 <warn>
775     Do not run more than one of the above programs at the same time. It may cause
776     confusion like switching between two frequencies all the time.
777     </warn>
778    
779 swift 1.8 </body>
780     </section>
781     <section>
782     <title>Verifying the result</title>
783     <body>
784    
785 swift 1.1 <p>
786     The last thing to check is that your new policies do a good job. An easy way to
787 swift 1.8 do so is monitoring CPU speed while working with your laptop:
788 swift 1.1 </p>
789    
790     <pre caption="Monitoring CPU speed">
791 yoswink 1.13 # <i>watch grep \"cpu MHz\" /proc/cpuinfo</i>
792 swift 1.1 </pre>
793    
794     <p>
795 rane 1.20 If <path>/proc/cpuinfo</path> doesn't get updated (see <uri
796 swift 1.32 link="#doc_chap8">Troubleshooting</uri>), monitor the CPU frequency with
797     <c>sys-apps/x86info</c>:
798 swift 1.1 </p>
799    
800     <pre caption="Alternative CPU speed monitoring">
801 neysx 1.12 # <i>watch x86info -mhz</i>
802 swift 1.1 </pre>
803    
804     <p>
805     Depending on your setup, CPU speed should increase on heavy load, decrease on
806 rane 1.19 no activity or just stay at the same level. When using <c>cpufreqd</c> and
807 rane 1.20 verbosity set to 5 or higher in <path>cpufreqd.conf</path> you'll get
808     additional information about what's happening reported to <c>syslog</c>.
809 swift 1.1 </p>
810    
811     </body>
812     </section>
813     </chapter>
814    
815     <chapter>
816     <title>LCD Power Management</title>
817     <section>
818     <body>
819    
820     <p>
821 rane 1.20 As you can see in <uri link="#doc_chap1_fig1">figure 1.1</uri>, the LCD
822     display consumes the biggest part of energy (might not be the case for
823     non-mobile CPU's). Thus it's quite important not only to shut the display off
824     when not needed, but also to reduce it's backlight if possible. Most laptops
825     offer the possibility to control the backlight dimming.
826 swift 1.1 </p>
827    
828 nightmorph 1.17 </body>
829     </section>
830     <section>
831     <title>Standby settings</title>
832     <body>
833    
834 swift 1.1 <p>
835 nightmorph 1.17 The first thing to check is the standby/suspend/off timings of the display. As
836     this depends heavily on your windowmanager, I'll let you figure it out
837 rane 1.20 yourself. Just two common places: Blanking the terminal can be done with
838 nightmorph 1.17 <c>setterm -blank &lt;number-of-minutesM&gt;</c>, <c>setterm -powersave on</c>
839     and <c>setterm -powerdown &lt;number-of-minutesM&gt;</c>. For X.org, modify
840     <path>/etc/X11/xorg.conf</path> similar to this:
841 swift 1.1 </p>
842    
843 nightmorph 1.35 <pre caption="LCD suspend settings in X.org">
844     Section "ServerFlags"
845     Option "blank time" "5" <comment># Blank the screen after 5 minutes (Fake)</comment>
846     Option "standby time" "10" <comment># Turn off screen after 10 minutes (DPMS)</comment>
847     Option "suspend time" "20" <comment># Full suspend after 20 minutes</comment>
848     Option "off time" "30" <comment># Turn off after half an hour</comment>
849 swift 1.1 [...]
850     EndSection
851    
852     [...]
853    
854     Section "Monitor"
855     Identifier [...]
856 nightmorph 1.35 Option "DPMS"
857 swift 1.1 [...]
858     EndSection
859     </pre>
860    
861 nightmorph 1.17 </body>
862     </section>
863     <section>
864     <title>Backlight dimming</title>
865     <body>
866    
867 swift 1.1 <p>
868     Probably more important is the backlight dimming. If you have access to the
869     dimming settings via a tool, write a small script that dims the backlight in
870 rane 1.19 battery mode and place it in your <c>battery</c> runlevel. The following script
871 nightmorph 1.17 should work on most IBM Thinkpads and Toshiba laptops. You've got to enable the
872 rane 1.20 appropriate option in your kernel (IBM Thinkpads only). For Toshiba laptops,
873 nightmorph 1.35 install <c>sys-power/acpitool</c> and skip configuration of <c>thinkpad_acpi</c>
874     (formerly called <c>ibm_acpi</c>) as described below.
875 neysx 1.12 </p>
876    
877     <warn>
878 swift 1.36 Support for setting brightness is marked experimental in thinkpad_acpi. It
879     accesses hardware directly and may cause severe harm to your system. Please
880     read the <uri link="http://ibm-acpi.sourceforge.net/">thinkpad_acpi
881     website</uri>
882 neysx 1.12 </warn>
883    
884     <p>
885 swift 1.36 To be able to set the brightness level, the thinkpad_acpi module has to be
886     loaded with the experimental parameter.
887 neysx 1.12 </p>
888    
889 nightmorph 1.35 <pre caption="automatically loading the thinkpad_acpi module">
890 neysx 1.12 <comment>(Please read the warnings above before doing this!)</comment>
891 nightmorph 1.37 # <i>echo "options thinkpad_acpi experimental=1" >> /etc/modprobe.d/thinkpad_acpi</i>
892     # <i>update-modules</i>
893 nightmorph 1.35 # <i>echo thinkpad_acpi >> /etc/modules.autoload.d/kernel-2.6</i>
894     # <i>modprobe thinkpad_acpi</i>
895 neysx 1.12 </pre>
896    
897     <p>
898     This should work without error messages and a file
899     <path>/proc/acpi/ibm/brightness</path> should be created after loading the
900 rane 1.20 module. An init script will take care of choosing the brightness according to
901     the power source.
902 neysx 1.12 </p>
903    
904     <pre caption="/etc/conf.d/lcd-brightness">
905     <comment># See /proc/acpi/ibm/brightness for available values</comment>
906 nightmorph 1.35 <comment># Please read /usr/src/linux/Documentation/thinkpad-acpi.txt</comment>
907 neysx 1.12
908 nightmorph 1.23 <comment># brightness level in ac mode. Default is 7.</comment>
909 neysx 1.12 BRIGHTNESS_AC=7
910    
911     <comment># brightness level in battery mode. Default is 4.</comment>
912     BRIGHTNESS_BATTERY=4
913     </pre>
914    
915     <pre caption="/etc/init.d/lcd-brightness">
916     #!/sbin/runscript
917    
918     set_brightness() {
919     if on_ac_power
920     then
921     LEVEL=${BRIGHTNESS_AC:-7}
922     else
923     LEVEL=${BRIGHTNESS_BATTERY:-4}
924     fi
925    
926     if [ -f /proc/acpi/ibm/brightness ]
927     then
928     ebegin "Setting LCD brightness"
929     echo "level ${LEVEL}" > /proc/acpi/ibm/brightness
930     eend $?
931 nightmorph 1.17 elif [[ -e /usr/bin/acpitool &amp;&amp; -n $(acpitool -T | grep "LCD brightness") ]]
932     then
933     ebegin "Setting LCD brightness"
934     acpitool -l $LEVEL >/dev/null || ewarn "Unable to set lcd brightness"
935     eend $?
936 neysx 1.12 else
937     ewarn "Setting LCD brightness is not supported."
938 nightmorph 1.35 ewarn "For IBM Thinkpads, check that thinkpad_acpi is loaded into the kernel"
939 nightmorph 1.23 ewarn "For Toshiba laptops, you've got to install sys-power/acpitool"
940 neysx 1.12 fi
941     }
942    
943     start() {
944     set_brightness
945     }
946    
947     stop () {
948     set_brightness
949     }
950     </pre>
951    
952     <p>
953     When done, make sure brightness is adjusted automatically by adding it to the
954     battery runlevel.
955 swift 1.1 </p>
956    
957 neysx 1.12 <pre caption="Enabling automatic brightness adjustment">
958 rane 1.19 # <i>chmod +x /etc/init.d/lcd-brightness</i>
959     # <i>rc-update add lcd-brightness battery</i>
960     # <i>rc</i>
961 neysx 1.12 </pre>
962    
963 swift 1.1 </body>
964     </section>
965     </chapter>
966    
967     <chapter>
968     <title>Disk Power Management</title>
969     <section>
970 nightmorph 1.17 <body>
971 rane 1.19
972 nightmorph 1.17 <p>
973     Hard disks consume less energy in sleep mode. Therefore it makes sense to
974     activate power saving features whenever the hard disk is not used for a certain
975     amount of time. I'll show you two alternative possibilities to do it. First,
976     laptop-mode will save most energy due to several measures which prevent or at
977     least delay write accesses. The drawback is that due to the delayed write
978     accesses a power outage or kernel crash will be more dangerous for data loss.
979     If you don't like this, you have to make sure that there are no processes which
980     write to your hard disk frequently. Afterwards you can enable power saving
981 rane 1.19 features of your hard disk with <c>hdparm</c> as the second alternative.
982 nightmorph 1.17 </p>
983    
984     </body>
985     </section>
986     <section>
987     <title>Increasing idle time - laptop-mode</title>
988 swift 1.1 <body>
989    
990     <p>
991 nightmorph 1.27 Recent 2.6 kernels include the so-called <c>laptop-mode</c>. When activated,
992     dirty buffers are written to disk on read calls or after 10 minutes (instead of
993     30 seconds). This minimizes the time the hard disk needs to be spun up.
994 swift 1.1 </p>
995    
996 nightmorph 1.17 <pre caption="Automated start of laptop-mode">
997     # <i>emerge laptop-mode-tools</i>
998     </pre>
999 swift 1.1
1000 nightmorph 1.17 <p>
1001     <c>laptop-mode-tools</c> has its configuration file in
1002     <path>/etc/laptop-mode/laptop-mode.conf</path>. Adjust it the way you like it,
1003     it's well commented. Run <c>rc-update add laptop_mode battery</c> to start it
1004     automatically.
1005     </p>
1006    
1007     <p>
1008     Recent versions (1.11 and later) of laptop-mode-tools include a new tool
1009     <c>lm-profiler</c>. It will monitor your system's disk usage and running
1010     network services and suggests to disable unneeded ones. You can either disable
1011     them through laptop-mode-tools builtin runlevel support (which will be reverted
1012 rane 1.19 by Gentoo's <c>/sbin/rc</c>) or use your <c>default</c>/<c>battery</c>
1013 nightmorph 1.17 runlevels (recommended).
1014     </p>
1015    
1016     <pre caption="Sample output from running lm-profiler">
1017 rane 1.19 # <i>lm-profiler</i>
1018 nightmorph 1.17 Profiling session started.
1019     Time remaining: 600 seconds
1020     [4296896.602000] amarokapp
1021     Time remaining: 599 seconds
1022     [4296897.714000] sort
1023     [4296897.970000] mv
1024     Time remaining: 598 seconds
1025     Time remaining: 597 seconds
1026     [4296900.482000] reiserfs/0
1027     </pre>
1028    
1029     <p>
1030     After profiling your system for ten minutes, lm-profiler will present a list of
1031     services which might have caused disk accesses during that time.
1032     </p>
1033    
1034     <pre caption="lm-profiler suggests to disable some services">
1035     Program: "atd"
1036     Reason: standard recommendation (program may not be running)
1037     Init script: /etc/init.d/atd (GUESSED)
1038    
1039 rane 1.19 Do you want to disable this service in battery mode? [y/N]: <i>n</i>
1040 swift 1.1 </pre>
1041    
1042     <p>
1043 nightmorph 1.17 To disable atd as suggested in the example above, you would run <c>rc-update
1044     del atd battery</c>. Be careful not to disable services that are needed for
1045 rane 1.20 your system to run properly - <c>lm-profiler</c> is likely to generate some
1046     false positives. Do not disable a service if you are unsure whether it's
1047     needed.
1048 nightmorph 1.17 </p>
1049    
1050     </body>
1051     </section>
1052     <section>
1053 rane 1.19 <title>Limiting Write Accesses</title>
1054 nightmorph 1.17 <body>
1055    
1056     <p>
1057     If you don't want to use laptop-mode, you must take special care to disable
1058     services that write to your disk frequently - <c>syslogd</c> is a good
1059     candidate, for example. You probably don't want to shut it down completely, but
1060     it's possible to modify the config file so that "unnecessary" things don't get
1061 rane 1.20 logged and thus don't create disk traffic. <c>Cups</c> writes to disk
1062     periodically, so consider shutting it down and only enable it manually when
1063     needed.
1064 nightmorph 1.17 </p>
1065    
1066     <pre caption="Disabling cups in battery mode">
1067     # <i>rc-update del cupsd battery</i>
1068     </pre>
1069    
1070     <p>
1071     You can also use <c>lm-profiler</c> from laptop-mode-tools (see above) to find
1072     services to disable. Once you eliminated all of them, go on with configuring
1073     hdparm.
1074     </p>
1075    
1076     </body>
1077     </section>
1078     <section>
1079     <title>hdparm</title>
1080     <body>
1081    
1082     <p>
1083 nightmorph 1.28 The second possibility is using <c>hdparm</c>. Skip this if
1084     you are using laptop-mode. Otherwise, edit <path>/etc/conf.d/hdparm</path> and
1085     add the following values to your drive entries. This example assumes your hard
1086     drive is called <b>hda</b>:
1087 swift 1.1 </p>
1088    
1089 nightmorph 1.28 <pre caption="Using /etc/conf.d/hdparm for disk standby">
1090     hda_args="-q -S12"
1091     </pre>
1092 neysx 1.12
1093 nightmorph 1.28 <p>
1094     This will activate power management for your hard drive. If you ever want to
1095     deactivate power management, you can edit <path>/etc/conf.d/hdparm</path> and
1096     change the values to <c>-q -S0</c>, or just run <c>hdparm -q -S0 /dev/hda</c>.
1097     </p>
1098 swift 1.1
1099     <p>
1100 nightmorph 1.28 See <c>man hdparm</c> for the options. Though you can always start <c>hdparm</c>
1101     manually when you are on battery power by running <c>/etc/init.d/hdparm
1102     start</c>, it's much easier to automate its startup and shutdown. To do so, add
1103     <c>hdparm</c> to the battery runlevel so that it will automatically enable power
1104     management.
1105 swift 1.1 </p>
1106    
1107     <pre caption="Automate disk standby settings">
1108 nightmorph 1.28 # <i>rc-update add hdparm battery</i>
1109 swift 1.1 </pre>
1110    
1111     <impo>
1112     Be careful with sleep/spin down settings of your hard drive. Setting it to
1113     small values might wear out your drive and lose warranty.
1114     </impo>
1115    
1116     </body>
1117     </section>
1118     <section>
1119     <title>Other tricks</title>
1120     <body>
1121    
1122     <p>
1123     Another possibility is to deactivate swap in battery mode. Before writing a
1124     swapon/swapoff switcher, make sure there is enough RAM and swap isn't used
1125     heavily, otherwise you'll be in big problems.
1126     </p>
1127    
1128     <p>
1129     If you don't want to use laptop-mode, it's still possible to minimize disk
1130 rane 1.19 access by mounting certain directories as <c>tmpfs</c> - write accesses are not
1131 swift 1.1 stored on a disk, but in main memory and get lost with unmounting. Often it's
1132     useful to mount <path>/tmp</path> like this - you don't have to pay special
1133     attention as it gets cleared on every reboot regardless whether it was mounted
1134     on disk or in RAM. Just make sure you have enough RAM and no program (like a
1135     download client or compress utility) needs extraordinary much space in
1136     <path>/tmp</path>. To activate this, enable tmpfs support in your kernel and
1137     add a line to <path>/etc/fstab</path> like this:
1138     </p>
1139    
1140     <pre caption="Editing /etc/fstab to make /tmp even more volatile">
1141     none /tmp tmpfs size=32m 0 0
1142     </pre>
1143    
1144     <warn>
1145     Pay attention to the size parameter and modify it for your system. If you're
1146 rane 1.21 unsure, don't try this at all, it can become a performance bottleneck easily. In
1147 swift 1.1 case you want to mount <path>/var/log</path> like this, make sure to merge the
1148     log files to disk before unmounting. They are essential. Don't attempt to mount
1149 rane 1.19 <path>/var/tmp</path> like this. Portage uses it for compiling...
1150 swift 1.1 </warn>
1151    
1152     </body>
1153     </section>
1154     </chapter>
1155    
1156     <chapter>
1157 rane 1.19 <title>Power Management For Other Devices</title>
1158 swift 1.1 <section>
1159 rane 1.19 <title>Graphics Cards</title>
1160 so 1.15 <body>
1161    
1162     <p>
1163     In case you own an ATI graphics card supporting PowerPlay (dynamic clock
1164 nightmorph 1.25 scaling for the graphics processing unit GPU), you can activate this
1165 rane 1.20 feature in X.org. Open <path>/etc/X11/xorg.conf</path> and add (or enable) the
1166     <c>DynamicClocks</c> option in the Device section. Please notice that this
1167     feature will lead to crashes on some systems.
1168 so 1.15 </p>
1169    
1170     <pre caption="Enabling ATI PowerPlay support in X.org">
1171     Section "Device"
1172     [...]
1173     Option "DynamicClocks" "on"
1174     EndSection
1175     </pre>
1176    
1177     </body>
1178     </section>
1179     <section>
1180 swift 1.1 <title>Wireless Power Management</title>
1181     <body>
1182    
1183     <p>
1184 nightmorph 1.17 Wireless LAN cards consume quite a bit of energy. Put them in Power Management
1185 nightmorph 1.28 mode just like your hard drives.
1186 swift 1.1 </p>
1187    
1188 nightmorph 1.17 <note>
1189     This script assumes your wireless interface is called <c>wlan0</c>; replace
1190     this with the actual name of your interface.
1191     </note>
1192    
1193 nightmorph 1.28 <p>
1194 nightmorph 1.29 Add the following option to <path>/etc/conf.d/net</path> to automatically enable
1195 nightmorph 1.28 power management for your wireless card:
1196     </p>
1197 swift 1.1
1198 nightmorph 1.28 <pre caption="Automated WLAN Power Management">
1199     iwconfig_wlan0="power on"
1200 swift 1.1 </pre>
1201    
1202     <p>
1203 nightmorph 1.28 See <c>man iwconfig</c> for details and more options like the period between
1204     wakeups or timeout settings. If your driver and access point support changing
1205     the beacon time, this is a good starting point to save even more energy.
1206 swift 1.1 </p>
1207    
1208     </body>
1209     </section>
1210     <section>
1211     <title>USB Power Management</title>
1212     <body>
1213    
1214     <p>
1215     There are two problems with USB devices regarding energy consumption: First,
1216     devices like USB mice, digital cameras or USB sticks consume energy while
1217     plugged in. You cannot avoid this (nevertheless remove them in case they're not
1218     needed). Second, when there are USB devices plugged in, the USB host controller
1219     periodically accesses the bus which in turn prevents the CPU from going into
1220 rane 1.20 sleep mode. The kernel offers an experimental option to enable suspension of
1221 so 1.15 USB devices through driver calls or one of the <path>power/state</path> files
1222     in <path>/sys</path>.
1223 swift 1.1 </p>
1224    
1225 so 1.15 <pre caption="Enabling USB suspend support in the kernel">
1226     Device Drivers
1227     USB support
1228     [*] Support for Host-side USB
1229     [*] USB suspend/resume (EXPERIMENTAL)
1230     </pre>
1231    
1232 swift 1.1 </body>
1233     </section>
1234     </chapter>
1235    
1236     <chapter>
1237 rane 1.19 <title>Sleep States: sleep, standby, and suspend to disk</title>
1238 swift 1.1 <section>
1239     <body>
1240    
1241     <p>
1242     ACPI defines different sleep states. The more important ones are
1243     </p>
1244    
1245 rane 1.20 <ul>
1246 swift 1.1 <li>S1 aka Standby</li>
1247     <li>S3 aka Suspend to RAM aka Sleep</li>
1248     <li>S4 aka Suspend to Disk aka Hibernate</li>
1249     </ul>
1250    
1251     <p>
1252     They can be called whenever the system is not in use, but a shutdown is not
1253     wanted due to the long boot time.
1254     </p>
1255    
1256     </body>
1257     </section>
1258     <section>
1259 so 1.15 <title>Sleep (S3)</title>
1260 swift 1.1 <body>
1261    
1262     <p>
1263 so 1.15 The ACPI support for these sleep states is marked experimental for good reason.
1264     APM sleep states seem to be more stable, however you can't use APM and ACPI
1265     together.
1266     </p>
1267    
1268     <pre caption="Kernel configuration for the various suspend types">
1269     Power Management Options ---&gt;
1270     [*] Power Management support
1271 nightmorph 1.40 [*] Suspend to RAM and standby
1272 so 1.15 </pre>
1273    
1274     <p>
1275 nightmorph 1.17 Once your kernel is properly configured, you can use the
1276 so 1.15 <c>hibernate-script</c> to activate suspend or sleep mode. Let's install that
1277     first.
1278     </p>
1279    
1280     <pre caption="Installing the hibernate-script">
1281 rane 1.19 # <i>emerge hibernate-script</i>
1282 so 1.15 </pre>
1283    
1284     <p>
1285 nightmorph 1.25 Some configuration has to be done in <path>/etc/hibernate</path>. The default
1286 nightmorph 1.24 package introduces a few configuration files for each sleep state. Options that
1287     are common to all suspend methods are placed in <path>common.conf</path>; make
1288     sure this file is properly set up for your system.
1289 so 1.15 </p>
1290    
1291     <p>
1292 nightmorph 1.24 To configure sleep, edit <path>sysfs-ram.conf</path> in
1293     <path>/etc/hibernate</path>. <c>UseSysfsPowerState mem</c> is already setup
1294 nightmorph 1.25 correctly, but if you need to make further changes to this particular sleep
1295     state (or any other sleep state) you should add them to
1296 nightmorph 1.24 <path>/etc/hibernate/hibernate.conf</path>. The comments and option names will
1297     guide you. If you use nfs or samba shares over the network, make sure to
1298     shutdown the appropriate init scripts to avoid timeouts.
1299 so 1.15 </p>
1300    
1301 nightmorph 1.24 <note>
1302     For more information on setting up sleep states, read <c>man
1303     hibernate.conf</c>.
1304     </note>
1305    
1306 so 1.15 <p>
1307     Ready? Now is the last chance to backup any data you want to keep after
1308     executing the next command. Notice that you probably have to hit a special key
1309 rane 1.19 like <c>Fn</c> to resume from sleep.
1310 so 1.15 </p>
1311    
1312     <pre caption="Calling sleep">
1313 rane 1.19 # <i>hibernate-ram</i>
1314 so 1.15 </pre>
1315    
1316     <p>
1317 rane 1.20 If you're still reading, it seems to work. You can also setup standby (S1) in a
1318 nightmorph 1.24 similar way by editing <path>sysfs-ram.conf</path> and changing
1319     "UseSysfsPowerState mem" to "UseSysfsPowerState standby". S3 and S4 are the more
1320     interesting sleep states due to greater energy savings however.
1321 so 1.15 </p>
1322    
1323     </body>
1324     </section>
1325     <section>
1326     <title>Hibernate (S4)</title>
1327     <body>
1328    
1329     <p>
1330     This section introduces hibernation, where a snapshot of the running system is
1331     written to disk before powering off. On resume, the snapshot is loaded and you
1332     can go on working at exactly the point you called hibernate before.
1333 swift 1.1 </p>
1334    
1335     <warn>
1336 so 1.15 Don't exchange non hot-pluggable hardware when suspended. Don't attempt to load
1337     a snapshot with a different kernel image than the one it was created with.
1338     Shutdown any NFS or samba server/client before hibernating.
1339 swift 1.1 </warn>
1340    
1341     <p>
1342 so 1.15 There are two different implementations for S4. The original one is swsusp,
1343 nightmorph 1.39 then there is the newer tuxonice (formerly suspend2) with a nicer interface
1344 swift 1.36 (including fbsplash support). A <uri
1345 nightmorph 1.39 link="http://tuxonice.net/features.html#compare">feature comparison</uri> is
1346     available at the <uri link="http://www.tuxonice.net">tuxonice homepage</uri>.
1347 swift 1.36 There used to be Suspend-to-Disk (pmdisk), a fork of swsusp, but it has been
1348     merged back.
1349 swift 1.1 </p>
1350    
1351     <p>
1352 jkt 1.33 TuxOnIce is not included in the mainline kernel yet, therefore you either have
1353 rane 1.20 to patch your kernel sources with the patches provided by <uri
1354 nightmorph 1.39 link="http://www.tuxonice.net">tuxonice.net</uri> or use
1355 jkt 1.33 <c>sys-kernel/tuxonice-sources</c>.
1356 swift 1.1 </p>
1357    
1358     <p>
1359 jkt 1.33 The kernel part for both swusp and TuxOnIce is as follows:
1360 swift 1.1 </p>
1361    
1362     <pre caption="Kernel configuration for the various suspend types">
1363 nightmorph 1.40 Power Management support ---&gt;
1364 swift 1.1 <comment>(hibernate with swsusp)</comment>
1365 nightmorph 1.39 [*] Hibernation (aka 'suspend to disk')
1366 so 1.15 <comment>(replace /dev/SWAP with your swap partition)</comment>
1367     (/dev/SWAP) Default resume partition
1368 rane 1.20
1369 jkt 1.33 <comment>(hibernate with TuxOnIce)</comment>
1370     Enhanced Hibernation (TuxOnIce)
1371 nightmorph 1.39 --- Image Storage (you need at least one allocator)
1372     [*] File Allocator
1373     [*] Swap Allocator
1374 so 1.15 --- General Options
1375 nightmorph 1.39 [*] Compression support
1376 so 1.15 [ ] Allow Keep Image Mode
1377 nightmorph 1.39 [*] Replace swsusp by default
1378 swift 1.1 </pre>
1379    
1380     <p>
1381 so 1.15 The configuration for swsusp is rather easy. If you didn't store the location
1382     of your swap partition in the kernel config, you can also pass it as a
1383     parameter with the <c>resume=/dev/SWAP</c> directive. If booting is not
1384     possible due to a broken image, use the <c>noresume</c> kernel parameter. The
1385 rane 1.20 <c>hibernate-cleanup</c> init script invalidates swsusp images during the boot
1386     process.
1387 swift 1.1 </p>
1388    
1389 so 1.15 <pre caption="Invalidating swsusp images during the boot process">
1390 rane 1.19 # <i>rc-update add hibernate-cleanup boot</i>
1391 so 1.15 </pre>
1392    
1393 swift 1.1 <p>
1394 so 1.15 To activate hibernate with swsusp, use the hibernate script and set
1395 nightmorph 1.24 <c>UseSysfsPowerState disk</c> in <path>/etc/hibernate/sysfs-disk</path>.
1396 swift 1.1 </p>
1397    
1398     <warn>
1399     Backup your data before doing this. Run <c>sync</c> before executing one of the
1400     commands to have cached data written to disk. First try it outside of X, then
1401     with X running, but not logged in.
1402     </warn>
1403 rane 1.20
1404 swift 1.1 <p>
1405     If you experience kernel panics due to uhci or similar, try to compile USB
1406     support as module and unload the modules before sending your laptop to sleep
1407 nightmorph 1.24 mode. There are configuration options for this in <path>common.conf</path>
1408 swift 1.1 </p>
1409    
1410 so 1.15 <pre caption="Hibernating with swsusp">
1411 nightmorph 1.24 # <i>nano -w /etc/hibernate/common.conf</i>
1412 so 1.15 <comment>(Make sure you have a backup of your data)</comment>
1413 rane 1.19 # <i>hibernate</i>
1414 so 1.15 </pre>
1415    
1416 swift 1.1 <p>
1417 jkt 1.34 The following section discusses the setup of TuxOnIce including fbsplash support
1418     for a nice graphical progress bar during suspend and resume.
1419 so 1.15 </p>
1420    
1421     <p>
1422 rane 1.20 The first part of the configuration is similar to the configuration of swsusp.
1423     In case you didn't store the location of your swap partition in the kernel
1424     config, you have to pass it as a kernel parameter with the
1425 jkt 1.33 <c>resume=swap:/dev/SWAP</c> directive. If booting is not possible due to a
1426     broken image, append the <c>noresume</c> parameter. Additionally, the
1427 jkt 1.34 <c>hibernate-cleanup</c> init script invalidates TuxOnIce images during the boot
1428     process.
1429 so 1.15 </p>
1430    
1431 jkt 1.33 <pre caption="Invalidating TuxOnIce images during the boot process">
1432 rane 1.19 # <i>rc-update add hibernate-cleanup boot</i>
1433 so 1.15 </pre>
1434    
1435 rane 1.20 <p>
1436 nightmorph 1.39 Now edit <path>/etc/hibernate/tuxonice.conf</path>, enable the <c>TuxOnIce</c>
1437 nightmorph 1.24 options you need. Do not enable the <c>fbsplash</c> options in
1438     <c>common.conf</c> just yet.
1439 swift 1.1 </p>
1440    
1441 jkt 1.33 <pre caption="Hibernating with TuxOnIce">
1442 nightmorph 1.39 # <i>nano -w /etc/hibernate/tuxonice.conf</i>
1443 so 1.15 <comment>(Make sure you have a backup of your data)</comment>
1444 rane 1.19 # <i>hibernate</i>
1445 swift 1.8 </pre>
1446    
1447 so 1.15 <p>
1448 rane 1.20 Please configure <c>fbsplash</c> now if you didn't do already. To enable
1449 jkt 1.34 fbsplash support during hibernation, the <c>sys-apps/tuxonice-userui</c> package
1450     is needed. Additionally, you've got to enable the <c>fbsplash</c> USE flag.
1451 so 1.15 </p>
1452    
1453 jkt 1.33 <pre caption="Installing tuxonice-userui">
1454     # <i>echo "sys-apps/tuxonice-userui fbsplash" >> /etc/portage/package.use</i>
1455     # <i>emerge tuxonice-userui</i>
1456 so 1.15 </pre>
1457    
1458     <p>
1459     The ebuild tells you to make a symlink to the theme you want to use. For
1460     example, to use the <c>livecd-2005.1</c> theme, run the following command:
1461     </p>
1462    
1463     <pre caption="Using the livecd-2005.1 theme during hibernation">
1464 nightmorph 1.39 # <i>ln -sfn /etc/splash/livecd-2005.1 /etc/splash/tuxonice</i>
1465 so 1.15 </pre>
1466    
1467     <p>
1468     If you don't want a black screen in the first part of the resume process, you
1469 jkt 1.33 have to add the <c>tuxoniceui_fbsplash</c> tool to your initrd image. Assuming
1470 so 1.15 you created the initrd image with <c>splash_geninitramfs</c> and saved it as
1471 rane 1.20 <path>/boot/fbsplash-emergence-1024x768</path>, here's how to do that.
1472 so 1.15 </p>
1473    
1474 jkt 1.33 <pre caption="Adding tuxoniceui_fbsplash to an initrd image">
1475 rane 1.19 # <i>mount /boot</i>
1476     # <i>mkdir ~/initrd.d</i>
1477     # <i>cp /boot/fbsplash-emergence-1024x768 ~/initrd.d/</i>
1478     # <i>cd ~/initrd.d</i>
1479     # <i>gunzip -c fbsplash-emergence-1024x768 | cpio -idm --quiet -H newc</i>
1480     # <i>rm fbsplash-emergence-1024x768</i>
1481 jkt 1.33 # <i>cp /usr/sbin/tuxoniceui_fbsplash sbin/</i>
1482     # <i>find . | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/fbsplash-tuxonice-emergence-1024x768</i>
1483 so 1.15 </pre>
1484    
1485     <p>
1486 nightmorph 1.24 Afterwards adjust <path>grub.conf</path> (or <path>lilo.conf</path>) so that
1487 jkt 1.33 your TuxOnIce kernel uses
1488     <path>/boot/fbsplash-tuxonice-emergence-1024x768</path> as initrd image. You can
1489 nightmorph 1.24 now test a dry run to see if everything is setup correctly.
1490 so 1.15 </p>
1491    
1492     <pre caption="Test run for fbsplash hibernation">
1493 jkt 1.33 # <i>tuxoniceui_fbsplash -t</i>
1494 so 1.15 </pre>
1495    
1496     <p>
1497 nightmorph 1.24 Afterwards open <path>/etc/hibernate/common.conf</path> and activate the
1498     fbsplash options. Execute <c>hibernate</c> and enjoy.
1499 so 1.15 </p>
1500    
1501 swift 1.1 </body>
1502     </section>
1503     </chapter>
1504    
1505     <chapter>
1506     <title>Troubleshooting</title>
1507     <section>
1508     <body>
1509    
1510     <p>
1511     <e>Q:</e> I'm trying to change the CPU frequency, but
1512     <path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor</path> does not
1513     exist.
1514     </p>
1515    
1516     <p>
1517     <e>A:</e> Make sure your processor supports CPU frequency scaling and you chose
1518     the right CPUFreq driver for your processor. Here is a list of processors that
1519 jkt 1.34 are supported by cpufreq (kernel 2.6.7): ARM Integrator, ARM-SA1100, ARM-SA1110,
1520     AMD Elan - SC400, SC410, AMD mobile K6-2+, AMD mobile K6-3+, AMD mobile Duron,
1521     AMD mobile Athlon, AMD Opteron, AMD Athlon 64, Cyrix Media GXm, Intel mobile
1522     PIII and Intel mobile PIII-M on certain chipsets, Intel Pentium 4, Intel Xeon,
1523     Intel Pentium M (Centrino), National Semiconductors Geode GX, Transmeta Crusoe,
1524     VIA Cyrix 3 / C3, UltraSPARC-III, SuperH SH-3, SH-4, several "PowerBook" and
1525     "iBook2" and various processors on some ACPI 2.0-compatible systems (only if
1526     "ACPI Processor Performance States" are available to the ACPI/BIOS interface).
1527 swift 1.1 </p>
1528    
1529     <p>
1530     <e>Q:</e> My laptop supports frequency scaling, but
1531     <path>/sys/devices/system/cpu/cpu0/cpufreq/</path> is empty.
1532     </p>
1533    
1534     <p>
1535     <e>A:</e> Look for ACPI related error messages with <c>dmesg | grep ACPI</c>.
1536     Try to update the BIOS, especially if a broken DSDT is reported. You can also
1537     try to fix it yourself (which is beyond the scope of this guide).
1538     </p>
1539    
1540     <p>
1541 rane 1.19 <e>Q:</e> My laptop supports frequency scaling, but according to
1542     <path>/proc/cpuinfo</path> the speed never changes.
1543 swift 1.1 </p>
1544    
1545     <p>
1546 swift 1.8 <e>A:</e> Probably you have activated symmetric multiprocessing support
1547     (CONFIG_SMP) in your kernel. Deactivate it and it should work. Some older
1548 rane 1.20 kernels had a bug causing this. In that case, run <c>emerge x86info</c>, update
1549 jkt 1.34 your kernel as asked and check the current frequency with <c>x86info -mhz</c>.
1550 swift 1.1 </p>
1551    
1552     <p>
1553     <e>Q:</e> I can change the CPU frequency, but the range is not as wide as in
1554     another OS.
1555     </p>
1556    
1557     <p>
1558     <e>A:</e> You can combine frequency scaling with ACPI throttling to get a lower
1559 jkt 1.34 minimum frequency. Notice that throttling doesn't save much energy and is mainly
1560     used for thermal management (keeping your laptop cool and quiet). You can read
1561     the current throttling state with <c>cat /proc/acpi/processor/CPU/throttling</c>
1562     and change it with <c>echo -n "0:x" > /proc/acpi/processor/CPU/limit</c>, where
1563     x is one of the Tx states listed in
1564 swift 1.1 <path>/proc/acpi/processor/CPU/throttling</path>.
1565     </p>
1566    
1567     <p>
1568 swift 1.8 <e>Q:</e> When configuring the kernel, powersave, performance and userspace
1569     governors show up, but that ondemand thing is missing. Where do I get it?
1570     </p>
1571    
1572     <p>
1573     <e>A:</e> The ondemand governor is only included in recent kernel sources. Try
1574     updating them.
1575     </p>
1576    
1577     <p>
1578 swift 1.1 <e>Q:</e> Battery life time seems to be worse than before.
1579     </p>
1580    
1581     <p>
1582     <e>A:</e> Check your BIOS settings. Maybe you forgot to re-enable some of the
1583     settings.
1584     </p>
1585    
1586     <p>
1587     <e>Q:</e> My battery is charged, but KDE reports there would be 0% left and
1588     immediately shuts down.
1589     </p>
1590    
1591     <p>
1592     <e>A:</e> Check that battery support is compiled into your kernel. If you use
1593     it as a module, make sure the module is loaded.
1594     </p>
1595    
1596     <p>
1597 rane 1.20 <e>Q:</e> My system logger reports things like "logger: ACPI group battery /
1598     action battery is not defined".
1599 nightmorph 1.17 </p>
1600    
1601     <p>
1602 rane 1.20 <e>A:</e> This message is generated by the <path>/etc/acpi/default.sh</path>
1603     script that is shipped with acpid. You can safely ignore it. If you like to get
1604     rid of it, you can comment the appropriate line in
1605     <path>/etc/acpi/default.sh</path> as shown below:
1606 nightmorph 1.17 </p>
1607    
1608     <pre caption="Disabling warnings about unknown acpi events">
1609     *) # logger "ACPI action $action is not defined"
1610     </pre>
1611    
1612     <p>
1613 swift 1.1 <e>Q:</e> I have a Dell Inspiron 51XX and I don't get any ACPI events.
1614     </p>
1615    
1616     <p>
1617     <e>A:</e> This seems to be a kernel bug. Read on <uri
1618     link="http://bugme.osdl.org/show_bug.cgi?id=1752">here</uri>.
1619     </p>
1620    
1621     <p>
1622 rane 1.20 <e>Q:</e> I activated the <c>DynamicClocks</c> option in <path>xorg.conf</path>
1623     and now X.org crashes / the screen stays black / my laptop doesn't shutdown
1624 so 1.15 properly.
1625     </p>
1626    
1627     <p>
1628 rane 1.20 <e>A:</e> This happens on some systems. You have to disable
1629     <c>DynamicClocks</c>.
1630 so 1.15 </p>
1631    
1632     <p>
1633 jkt 1.33 <e>Q:</e> I want to use TuxOnIce, but it tells me my swap partition is too
1634 so 1.15 small. Resizing is not an option.
1635     </p>
1636    
1637     <p>
1638 rane 1.20 <e>A:</e> If there is enough free space on your system, you can use the
1639 jkt 1.34 filewriter instead of the swapwriter. The <c>hibernate-script</c> supports it as
1640     well. More information can be found in
1641 jkt 1.33 <path>/usr/src/linux/Documentation/power/tuxonice.txt</path>.
1642 so 1.15 </p>
1643    
1644     <p>
1645 swift 1.1 <e>Q:</e> I just bought a brand new battery, but it only lasts for some
1646     minutes! What am I doing wrong?
1647     </p>
1648    
1649     <p>
1650     <e>A:</e> First follow your manufacturer's advice on how to charge the battery
1651 rane 1.20 correctly.
1652 swift 1.1 </p>
1653    
1654     <p>
1655     <e>Q:</e> The above didn't help. What should I do then?
1656     </p>
1657    
1658     <p>
1659     <e>A:</e> Some batteries sold as "new" are in fact old ones. Try the following:
1660     </p>
1661    
1662     <pre caption="Querying battery state">
1663     $ <i>grep capacity /proc/acpi/battery/BAT0/info</i>
1664     design capacity: 47520 mWh
1665     last full capacity: 41830 mWh
1666     </pre>
1667    
1668     <p>
1669     If the "last full capacity" differs significantly from the design capacity,
1670     your battery is probably broken. Try to claim your warranty.
1671     </p>
1672    
1673 swift 1.8 <p>
1674     <e>Q:</e> My problem is not listed above. Where should I go next?
1675     </p>
1676    
1677     <p>
1678 nightmorph 1.17 <e>A:</e> Don't fear to contact me, <mail link="earthwings@gentoo.org">Dennis
1679 rane 1.20 Nienhüser</mail>, directly. The <uri link="http://forums.gentoo.org">Gentoo
1680     Forums</uri> are a good place to get help as well. If you prefer IRC, try the
1681 nightmorph 1.38 <c>#gentoo-laptop</c> <uri link="irc://irc.gentoo.org">channel</uri>.
1682 swift 1.8 </p>
1683    
1684 swift 1.1 </body>
1685     </section>
1686     </chapter>
1687     </guide>

  ViewVC Help
Powered by ViewVC 1.1.20