update for rename of docs/user/DebugKernelCrashDumps.mdwn to docs/user/list/DebugKern...
[ikiwiki.git] / docs / handbook / handbook-acpi-overview.mdwn
1 ## 6.15 Power and Resource Management \r
2 \r
3 ***Written by Hiten Pandya and Tom Rhodes. ***\r
4 \r
5 It is very important to utilize hardware resources in an efficient manner. Before ACPI was introduced, it was very difficult and inflexible for operating systems to manage the power usage and thermal properties of a system. The hardware was controlled by some sort of BIOS embedded interface, such as ***Plug and Play BIOS (PNPBIOS)***, or ***Advanced Power Management (APM)*** and so on. Power and Resource Management is one of the key components of a modern operating system. For example, you may want an operating system to monitor system limits (and possibly alert you) in case your system temperature increased unexpectedly.\r
6 \r
7 In this section, we will provide comprehensive information about ACPI. References will be provided for further reading at the end. Please be aware that ACPI is available on DragonFly systems as a default kernel module.\r
8 \r
9 ### 6.15.1 What Is ACPI? \r
10 \r
11 Advanced Configuration and Power Interface (ACPI) is a standard written by an alliance of vendors to provide a standard interface for hardware resources and power management (hence the name). It is a key element in ***Operating System-directed configuration and Power Management***, i.e.: it provides more control and flexibility to the operating system (OS). Modern systems ***stretched*** the limits of the current Plug and Play interfaces (such as APM), prior to the introduction of ACPI. ACPI is the direct successor to APM (Advanced Power Management).\r
12 \r
13 ### 6.15.2 Shortcomings of Advanced Power Management (APM) \r
14 \r
15 The ***Advanced Power Management (APM)*** facility control's the power usage of a system based on its activity. The APM BIOS is supplied by the (system) vendor and it is specific to the hardware platform. An APM driver in the OS mediates access to the ***APM Software Interface***, which allows management of power levels.\r
16 \r
17 There are four major problems in APM. Firstly, power management is done by the (vendor-specific) BIOS, and the OS does not have any knowledge of it. One example of this, is when the user sets idle-time values for a hard drive in the APM BIOS, that when exceeded, it (BIOS) would spin down the hard drive, without the consent of the OS. Secondly, the APM logic is embedded in the BIOS, and it operates outside the scope of the OS. This means users can only fix problems in their APM BIOS by flashing a new one into the ROM; which, is a very dangerous procedure, and if it fails, it could leave the system in an unrecoverable state. Thirdly, APM is a vendor-specific technology, which, means that there is a lot or parity (duplication of efforts) and bugs found in one vendor's BIOS, may not be solved in others. Last but not the least, the APM BIOS did not have enough room to implement a sophisticated power policy, or one that can adapt very well to the purpose of the machine.\r
18 \r
19 ***Plug and Play BIOS (PNPBIOS)*** was unreliable in many situations. PNPBIOS is 16-bit technology, so the OS has to use 16-bit emulation in order to ***interface*** with PNPBIOS methods.\r
20 \r
21 The DragonFly APM driver is documented in the [apm(4)](http://leaf.dragonflybsd.org/cgi/web-man?command#apm&section4) manual page.\r
22 \r
23 ### 6.15.3 Configuring ACPI \r
24 \r
25 The `acpi.ko` driver is loaded by default at start up by the [loader(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#loader&section8) and should ***not*** be compiled into the kernel. The reasoning behind this is that modules are easier to work with, say if switching to another `acpi.ko` without doing a kernel rebuild. This has the advantage of making testing easier. Another reason is that starting ACPI after a system has been brought up is not too useful, and in some cases can be fatal. In doubt, just disable ACPI all together. This driver should not and can not be unloaded because the system bus uses it for various hardware interactions. ACPI can be disabled with the [acpiconf(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=acpiconf&section=8) utility. In fact most of the interaction with ACPI can be done via [acpiconf(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=acpiconf&section=8). Basically this means, if anything about ACPI is in the [dmesg(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=dmesg&section=8) output, then most likely it is already running.\r
26 \r
27  **Note:** ACPI and APM cannot coexist and should be used separately. The last one to load will terminate if the driver notices the other running.\r
28 \r
29 In the simplest form, ACPI can be used to put the system into a sleep mode with [acpiconf(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#acpiconf&section8), the `-s` flag, and a `1-5` option. Most users will only need `1`. Option `5` will do a soft-off which is the same action as:\r
30 \r
31     \r
32     # halt -p\r
33 \r
34 \r
35 The other options are available. Check out the [acpiconf(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#acpiconf&section8) manual page for more information.\r