ACPI is a standard written by an alliance of vendors to provide a standard interface for hardware resources and power management. It is a key element in Operating System-directed configuration and Power Management as it provides more control and flexibility to the operating system. Modern systems “stretched” the limits of the current Plug and Play interfaces prior to the introduction of ACPI. ACPI is the direct successor to APM.

The APM facility controls the power usage of a system based on its activity. The APM BIOS is supplied by the vendor and is specific to the hardware platform. An APM driver in the operating system mediates access to the APM Software Interface, which allows management of power levels. APM should still be used for systems manufactured at or before the year 2000.

There are four major problems in APM. First, power management is done by the vendor-specific BIOS, separate from the operating system. For example, the user can set idle-time values for a hard drive in the APM BIOS so that, when exceeded, the BIOS spins down the hard drive without the consent of the operating system. Second, the APM logic is embedded in the BIOS, and it operates outside the scope of the operating system. This means that users can only fix problems in the APM BIOS by flashing a new one into the ROM, which is a dangerous procedure with the potential to leave the system in an unrecoverable state if it fails. Third, APM is a vendor-specific technology, meaning that there is a lot of duplication of efforts and bugs found in one vendor's BIOS may not be solved in others. Lastly, the APM BIOS did not have enough room to implement a sophisticated power policy or one that can adapt well to the purpose of the machine.

The Plug and Play BIOS (PNPBIOS) was unreliable in many situations. PNPBIOS is 16-bit technology, so the operating system has to use 16-bit emulation in order to interface with PNPBIOS methods.

The FreeBSD APM driver is documented in apm(4).

The acpi(4) driver is loaded by default at start up by loader(8) and should not be compiled into the kernel. The reasoning is that modules are easier to work with and do not require a kernel rebuild. This has the advantage of making testing easier. Another reason is that starting ACPI after a system has been brought up often does not work well. If experiencing problems, ACPI can be disabled altogether. This driver should not and can not be unloaded because the system bus uses it for various hardware interactions. ACPI can be disabled by rebooting after setting hint.acpi.0.disabled="1" in /boot/loader.conf or by setting this variable at the loader(8) prompt.

ACPI can be used to put the system into a sleep mode with acpiconf(8), the -s flag, and a 1-5 option. Most users only need 1 (quick suspend to RAM) or 3 (suspend to RAM). Option 5 performs a soft-off which is the same action as:

Other options are available via sysctl(8). Refer to acpi(4) and acpiconf(8) for more information.