Changeset View
Changeset View
Standalone View
Standalone View
documentation/content/en/books/handbook/config/_index.adoc
| Show First 20 Lines • Show All 1,329 Lines • ▼ Show 20 Lines | ||||||||||||||
| 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 APMBIOS 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 APMBIOS 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 APMBIOS did not have enough room to implement a sophisticated power policy or one that can adapt well to the purpose of the machine. | 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 APMBIOS 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 APMBIOS 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 APMBIOS 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. FreeBSD provides an APM driver as APM should still be used for systems manufactured at or before the year 2000. The driver is documented in man:apm[4]. | 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. FreeBSD provides an APM driver as APM should still be used for systems manufactured at or before the year 2000. The driver is documented in man:apm[4]. | |||||||||||||
| The successor to APM is the Advanced Configuration and Power Interface (ACPI). ACPI is a standard written by an alliance of vendors to provide an 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. | The successor to APM is the Advanced Configuration and Power Interface (ACPI). ACPI is a standard written by an alliance of vendors to provide an 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. | |||||||||||||
| This chapter demonstrates how to configure ACPI on FreeBSD. It then offers some tips on how to debug ACPI and how to submit a problem report containing debugging information so that developers can diagnosis and fix ACPI issues. | This chapter demonstrates how to configure ACPI on FreeBSD. It then offers some tips on how to debug ACPI and how to submit a problem report containing debugging information so that developers can diagnosis and fix ACPI issues. | |||||||||||||
| [[cpufreq]] | ||||||||||||||
| === CPU Frequency Control | ||||||||||||||
| FreeBSD includes a generic man:cpufreq[4] driver to allow the administrator, or software such as man:powerd[8] and package:sysutils/powerdxx[], to manage the frequency of the CPU to achieve the desired balance between performance and economy. | ||||||||||||||
| A lower setting will save power while reducing the heat generated by the CPU. | ||||||||||||||
| A higher setting will increase performance at the cost of using additional power and generating more heat. | ||||||||||||||
pauamma_gundo.com: Here, I'd mention when to use EST and when to use Speed Shift. Something like: "For 12.x… | ||||||||||||||
| [[est]] | ||||||||||||||
| === Intel(R) Enhanced Speed Step(TM) | ||||||||||||||
| The Intel(R) Enhanced Speed Step(TM) driver, man:est[4], replaces the generic man:cpufreq[4] driver for CPUs that provide this feature. | ||||||||||||||
Not Done Inline Actions
Trademarks on first use only. (Unless Intel wants them everywhere.) pauamma_gundo.com: Trademarks on first use only. (Unless Intel wants them everywhere.) | ||||||||||||||
| The CPU frequency can be statically adjusted using man:sysctl[8], or with the `/etc/rc.d/power_profile` startup script. | ||||||||||||||
| Additional software, such as man:powerd[8] or package:sysutils/powerdxx[], can be used to automatically adjust the CPU frequency based on processor utilization. | ||||||||||||||
| Each supported frequency, along with its expected power consumption, can be listed by examining the man:sysctl[3] tree: | ||||||||||||||
| ``` | ||||||||||||||
| root@host:~ # sysctl dev.cpufreq.0.freq_driver dev.cpu.0.freq_levels dev.cpu.0.freq | ||||||||||||||
| dev.cpufreq.0.freq_driver: est0 | ||||||||||||||
| dev.cpu.0.freq_levels: 3001/53000 3000/53000 2900/50301 2700/46082 2600/43525 2400/39557 2300/37137 2100/33398 2000/31112 1800/27610 1700/25455 1500/22171 1400/20144 1200/17084 1100/15181 900/12329 800/10550 | ||||||||||||||
| dev.cpu.0.freq: 800 | ||||||||||||||
| ``` | ||||||||||||||
| A frequency 1 MHz higher than the maximum frequency of the CPU indicates the Intel(R) Turbo Boost(TM) feature. | ||||||||||||||
| [[hwpstate_intel]] | ||||||||||||||
| === Intel Speed Shift(TM) | ||||||||||||||
| Users running newer Intel(R) CPUs may find some differences in dynamic frequency control when upgrading to FreeBSD 13.0. | ||||||||||||||
| A new driver for the Intel(R) Speed Shift(TM) feature set, available on certain SKUs, exposes the ability for the hardware to dynamically vary the core frequencies, including on a per core basis. | ||||||||||||||
Not Done Inline ActionsClarify: what are SKUs? pauamma_gundo.com: Clarify: what are SKUs? | ||||||||||||||
| FreeBSD 13.0 comes with the man:hwpstate_intel[4] driver to automatically enable Speed Shift(TM) control on equipped CPUs, replacing the older Enhanced Speed Step(TM) man:est[4] driver. | ||||||||||||||
Not Done Inline Actions
Or 13.x. pauamma_gundo.com: Or 13.x. | ||||||||||||||
| The man:sysctl[8] `dev.cpufreq.%d.freq_driver` will indicate if the system is using Speed Shift. | ||||||||||||||
Not Done Inline ActionsWhat is %d here? Can some but not all CPUs in a computer support Speed Shift? (This sentence and the next one probably belong above in the "which to use" intro paragraph, not here.) pauamma_gundo.com: What is %d here? Can some but not all CPUs in a computer support Speed Shift? (This sentence… | ||||||||||||||
| To determine which frequency control driver is being used, examining the `dev.cpufreq.0.freq_driver` oid. | ||||||||||||||
| ``` | ||||||||||||||
| root@host:~ # sysctl dev.cpufreq.0.freq_driver | ||||||||||||||
| dev.cpufreq.0.freq_driver: hwpstate_intel0 | ||||||||||||||
| ``` | ||||||||||||||
| This indicates that the new man:hwpstate_intel[4] driver is in use. | ||||||||||||||
| On such systems, the oid `dev.cpu.%d.freq_levels` will show only the maximum CPU frequency, and will indicate a power consumption level of `-1`. | ||||||||||||||
| The current CPU frequency can be determined by examining the `dev.cpu.%d.freq` oid. | ||||||||||||||
| ``` | ||||||||||||||
Not Done Inline Actionspauamma_gundo.com: See https://docs.freebsd.org/en/books/fdp-primer/asciidoctor-primer/#asciidoctor-primer… | ||||||||||||||
| root@host:~ # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq | ||||||||||||||
| dev.cpu.0.freq_levels: 3696/-1 | ||||||||||||||
| dev.cpu.0.freq: 898 | ||||||||||||||
| ``` | ||||||||||||||
| For more information, including on how to balance performance and energy use, and on how to disable this driver, refer to the man page man:hwpstate_intel[4]. | ||||||||||||||
| Note: Users accustomed to using man:powerd[8] or package:sysutils/powerdxx[] will find these utilities have been superseded by the man:hwpstate_intel[4] driver and no longer work as expected. | ||||||||||||||
Not Done Inline Actions
pauamma_gundo.com: | ||||||||||||||
| [[acpi-config]] | [[acpi-config]] | |||||||||||||
| === Configuring ACPI | === Configuring ACPI | |||||||||||||
| In FreeBSD the man:acpi[4] driver is loaded by default at system boot and should _not_ be compiled into the kernel. This driver cannot be unloaded after boot because the system bus uses it for various hardware interactions. However, if the system is experiencing problems, ACPI can be disabled altogether by rebooting after setting `hint.acpi.0.disabled="1"` in [.filename]#/boot/loader.conf# or by setting this variable at the loader prompt, as described in crossref:boot[boot-loader,“Stage Three”]. | In FreeBSD the man:acpi[4] driver is loaded by default at system boot and should _not_ be compiled into the kernel. This driver cannot be unloaded after boot because the system bus uses it for various hardware interactions. However, if the system is experiencing problems, ACPI can be disabled altogether by rebooting after setting `hint.acpi.0.disabled="1"` in [.filename]#/boot/loader.conf# or by setting this variable at the loader prompt, as described in crossref:boot[boot-loader,“Stage Three”]. | |||||||||||||
| [NOTE] | [NOTE] | |||||||||||||
| ==== | ==== | |||||||||||||
| ACPI and APM cannot coexist and should be used separately. The last one to load will terminate if the driver notices the other is running. | ACPI and APM cannot coexist and should be used separately. The last one to load will terminate if the driver notices the other is running. | |||||||||||||
| ▲ Show 20 Lines • Show All 205 Lines • Show Last 20 Lines | ||||||||||||||
Here, I'd mention when to use EST and when to use Speed Shift. Something like: "For 12.x, always use EST. For 13.x, do what sysctl dev.cpufreq.(whatever).freq_driver tells you." Or however the decision tree runs.