/[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.11 - (hide annotations) (download) (as text)
Mon Apr 18 19:19:27 2005 UTC (9 years, 8 months ago) by dertobi123
Branch: MAIN
Changes since 1.10: +4 -17 lines
File MIME type: application/xml
Added an missing emerge command, removed a faq. Requested by Dennis via IRC.

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

  ViewVC Help
Powered by ViewVC 1.1.20