acpitz(4) [netbsd man page]
ACPITZ(4) BSD Kernel Interfaces Manual ACPITZ(4) NAME
acpitz -- ACPI Thermal Zone SYNOPSIS
acpitz* at acpi? DESCRIPTION
The acpitz driver supports so-called ACPI ``Thermal Zones''. The temperature can be monitored by the envsys(4) API or the envstat(8) com- mand. The distinction between ``active'' and ``passive'' cooling is central to the abstractions behind acpitz. These are inversely related to each other: 1. Active cooling means that the system increases the power consumption of the machine by performing active thermal management (for exam- ple, by turning on a fan) in order to reduce the temperatures. 2. Passive cooling means that the system reduces the power consumption of devices at the cost of system performance (for example, by low- ering the CPU frequencies) in order to reduce the temperatures. Only active cooling is currently supported on NetBSD. It should be also noted that the internal functioning of these cooling policies vary across machines. On some machines the operating system may have little control over the thermal zones as the firmware manages the thermal control internally, whereas on other machines the policies may be exposed to the implementation at their full extent. EVENTS
The acpitz driver knows about the active cooling levels, the current temperatures, and critical, hot, and passive temperature thresholds (as supported by the hardware). The driver is able to send events to powerd(8) when the sensor's state has changed. When a Thermal Zone is either critical or ``hot'', the /etc/powerd/scripts/sensor_temperature script will be invoked with a critical-over event. The critical temperature is the threshold for system shutdown. Depending on the hardware, the mainboard will take down the system instantly and no event will have a chance to be sent. SEE ALSO
acpi(4), acpifan(4), envsys(4), envstat(8), powerd(8) HISTORY
The acpitz driver appeared in NetBSD 2.0. AUTHORS
Jared D. McNeill <jmcneill@invisible.ca> CAVEATS
While no pronounced bugs are known to exist, several caveats can be mentioned: o Passive cooling is not implemented. o There is no user-controllable way to switch between active and passive cooling, although the specifications support such transforms on some machines. o The ``hot'' temperature is a threshold in which the system ought to be put into S4 sleep. This sleep state (``suspend to disk'') is not supported on NetBSD. BSD
January 9, 2011 BSD
Check Out this Related Man Page
AIBS(4) BSD Kernel Interfaces Manual AIBS(4) NAME
aibs -- ASUSTeK AI Booster voltage, temperature, and fan sensor SYNOPSIS
aibs* at acpi? DESCRIPTION
The aibs driver provides support for voltage, temperature, and fan sensors available as an ACPI device on ASUSTeK motherboards. The number of sensors of each type, as well as the description of each sensor, varies according to the motherboard. The driver supports an arbitrary set of sensors, provides descriptions regarding what each sensor is used for, and reports whether each sen- sor is within the specifications as defined by the motherboard manufacturer through ACPI. The aibs driver supports envsys(4) sensor states as follows: o Voltage sensors can have a state of 'valid', 'critunder', or 'critover'; temperature sensors can have a state of 'valid', 'warnover', 'critover', or 'invalid'; and fan sensors can have a state of 'valid', 'warnunder', or 'warnover'. o Temperature sensors that have a reading of 0 are marked 'invalid', whereas all other sensors are always assumed valid. o Voltage sensors have a lower and an upper limit, 'critunder' and 'critover', temperature sensors have two upper limits, 'warnover' and 'critover', whereas fan sensors may either have only the lower limit 'warnunder', or, depending on the vendor's ACPI implementation, one lower and one upper limit, 'warnunder' and 'warnover'. Sensor values and limits are made available through the envsys(4) interface, and can be monitored with envstat(8). For example, on an ASUS V3-P5G965 barebone: $ envstat -d aibs0 Current CritMax WarnMax WarnMin CritMin Unit Vcore Voltage: 1.152 1.600 0.850 V +3.3 Voltage: 3.312 3.630 2.970 V +5 Voltage: 5.017 5.500 4.500 V +12 Voltage: 12.302 13.800 10.200 V CPU Temperature: 27.000 95.000 80.000 degC MB Temperature: 58.000 95.000 60.000 degC CPU FAN Speed: 878 7200 600 RPM CHASSIS FAN Speed: 0 7200 700 RPM Generally, sensors provided by the aibs driver may also be supported by a variety of other drivers, such as lm(4) or itesio(4). The precise collection of aibs sensors is comprised of the sensors specifically utilised in the motherboard design, which may be supported through a com- bination of one or more physical hardware monitoring chips. The aibs driver, however, provides the following advantages when compared to the native hardware monitoring drivers: o Sensor values from aibs are expected to be more reliable. For example, voltage sensors in many hardware monitoring chips can only sense voltage from 0 to 2 or 4 volts, and the excessive voltage is removed by the resistors, which may vary with the motherboard and with the voltage that is being sensed. In aibs, the required resistor factors are provided by the motherboard manufacturer through ACPI; in the native drivers, the resistor factors are encoded into the driver based on the chip manufacturer's recommendations. In essence, sensor values from aibs are very likely to be identical to the readings from the Hardware Monitor screen in the BIOS. o Sensor descriptions from aibs are more likely to match the markings on the motherboard. o Sensor states are supported by aibs. The state is reported based on the acceptable range of values for each individual sensor as sug- gested by the motherboard manufacturer. For example, the threshold for the CPU temperature sensor is likely to be significantly higher than that for the chassis temperature sensor. o Support for newer chips in aibs. Newer chips may miss a native driver, but should be supported through aibs regardless. As a result, sensor readings from the actual native hardware monitoring drivers are redundant when aibs is present, and may be ignored as appropriate. Whereas on some supported operating systems the native drivers may have to be specifically disabled should their presence be judged unnecessary, on others the drivers like lm(4) are not probed provided that acpi(4) is configured and the system potentially supports the hardware monitoring chip through ACPI. SEE ALSO
acpi(4), envsys(4), envstat(8) HISTORY
The aibs driver first appeared in OpenBSD 4.7, DragonFly 2.4.1 and NetBSD 6.0. An earlier version of the driver, named aiboost, first appeared in FreeBSD 7.0 and NetBSD 5.0. AUTHORS
The aibs driver was written for OpenBSD, DragonFly BSD, and NetBSD by Constantine A. Murenin <http://cnst.su/>, Raouf Boutaba Research Group, David R. Cheriton School of Computer Science, University of Waterloo. Jukka Ruohonen <jruohonen@iki.fi> later reworked and adjusted the driver to support new ASUSTeK motherboards. The earlier version of the driver, aiboost, was written for FreeBSD by Takanori Watanabe and adapted to NetBSD by Juan Romero Pardines. BSD
June 12, 2011 BSD