|POWER.CONF(5)||File Formats and Configurations||POWER.CONF(5)|
Power Management addresses two specific management scenarios: management of individual devices and management of the whole system. An individual device is power managed if the device supports multiple power levels and if the device driver uses Power Management interfaces provided by the kernel to save device power when the device is idle.
All entries in the power.conf file are processed in the order that they occur in the file.
When a component has been idle at a given power level for its threshold time, the power level of the component is reduced to the next lower power level of that component, if any. For devices which implement multiple components, each component is power-managed independently.
Default thresholds for components of automatically power managed devices are computed by the Power Management framework based on the system idleness threshold. By default, all components of the device are powered off if they have all been idle for the system's idleness threshold. The default system idleness threshold is determined by the applicable United States Environmental Protection Agency's (EPA) Energy Star Memorandum of Understanding. See the NOTES section of this manual page for more information.
To set the system idleness threshold, use one of the following entries:
where threshold is the value of the system idleness threshold in hours, minutes or seconds as indicated by a trailing h, m or s (defaulting to seconds if only a number is given). If always-on is specified, then by default, all devices are left at full power.
The system-threshold entry is applicable to CPU Power Management only when CPU Power Management has been configured to operate in poll-mode, which is expressed through the cpupm keyword.
If a system has power manageable CPUs, these can be managed independently of the system idleness threshold by using one of the following entries:
where threshold is the value of the CPU idleness threshold in hours, minutes or seconds as indicated by a trailing h, m or s (defaulting to seconds if only a number is given). If always-on is specified, then by default, all CPUs are left at full power.
The cpu-threshold keyword is used only when CPU Power Management has been configured to operate in poll-mode, which is expressed through the cpupm keyword.
If no cpu-threshold entry is specified, then the system idleness threshold is used.
To override the default device component thresholds assigned by the Power Management framework, a device-thresholds entry can be used. A device-thresholds entry sets thresholds for a specific automatically power-managed device or disables automatic Power Management for the specific device.
A device-thresholds entry has the form:
device-thresholds phys_path (threshold ...) ...
device-thresholds phys_path threshold
device-thresholds phys_path always-on
where phys_path specifies the physical path (libdevinfo(3LIB)) of a specific device. For example, /pci@8,600000/scsi@4/ssd@w210000203700c3ee,0 specifies the physical path of a disk. A symbolic link into the /devices tree, for example /dev/dsk/c1t1d0s0, is also accepted. The thresholds apply (or keeping the device always on applies) to the specific device only.
In the first form above, each threshold value represents the number of hours, minutes or seconds, depending on a trailing h, m or s with a default to seconds, to spend idle at the corresponding power level before power is reduced to the next lower level of that component. Parentheses are used to group thresholds per component, with the first (leftmost) group being applied to component 0, the next to component 1, and the like. Within a group, the last (rightmost) number represents the time to be idle in the highest power level of the component before going to the next-to-highest level, while the first (leftmost) number represents the time to be idle in the next-to-lowest power level before going to the lowest power level.
If the number of groups does not match the number of components exported by the device (by means of pm-components(9P) property), or the number of thresholds in a group is not one less than the number of power levels the corresponding component supports, then an error message is printed and the entry is ignored.
For example, assume a device called xfb exports the components Frame Buffer and Monitor. Component Frame Buffer has two power levels: Off and On. Component Monitor has four power levels: Off, Suspend, Standby, and On.
The following device-thresholds entry:
device-thresholds /pci@f0000/xfb@0 (0) (3m 5m 15m)
would set the threshold time for the Monitor component of the specific xfb card to go from On to Standby in 15 minutes, the threshold for Monitor to go from Standby to Suspend in 5 minutes, and the threshold for Monitor to go from Suspend to Off in 3 minutes. The threshold for Frame Buffer to go from On to Off is 0 seconds.
In the second form above, where a single threshold value is specified without parentheses, the threshold value represents a maximum overall time within which the entire device should be powered down if it is idle. Because the system does not know about any internal dependencies there can be among a device's components, the device can actually be powered down sooner than the specified threshold, but does take longer than the specified threshold, provided that all device components are idle.
In the third form above, all components of the device are left at full power.
Device Power Management entries are only effective if there is no user process controlling the device directly. For example, X Windows systems directly control frame buffers. The entries in the power.conf file are effective only when X Windows is not running.
Dependencies among devices can also be defined. A device depends upon another if none of its components might have their power levels reduced unless all components of the other device are powered off. A dependency can be indicated by an entry of the form:
device-dependency dependent_phys_path phys_path [ phys_path ... ]
where dependent_phys_path is the path name (as above) of the device that is kept up by the others, and the phys_path entries specify the devices that keep it up. A symbolic link into the /devices tree, such as /dev/fb, is also accepted. This entry is needed only for logical dependents for the device. A logical dependent is a device that is not physically connected to the power managed device (for example, the display and the keyboard). Physical dependents are automatically considered and need not be included.
In addition to listing dependents by physical path, an arbitrary group of devices can be made dependent upon another device by specifying a property dependency using the following syntax:
device-dependency-property property phys_path [phys_path ...]
where each device that exports the property property is kept up by the devices named by phys_path(s). A symbolic link into the /devices tree (such as /dev/fb) is accepted as well as a pathname for phys_path.
For example, the following entry ensures that every device that exports the boolean property named removable-media is kept up when the console framebuffer is up. See removable-media(9P).
# This entry keeps removable media from being powered down unless the # console framebuffer and monitor are powered down # (See removable-media(9P)) # device-dependency-property removable-media /dev/fb
An autopm entry can be used to enable or disable automatic device Power Management on a system-wide basis. The format of the autopm entry is:
Acceptable behavior values are described as follows:
A cpupm entry can be used to enable or disable Power Management of CPUs on a system-wide basis, independent of autopm. The format of the cpupm entry is:
Acceptable behavior values and their meanings are :
Where the behavior is enable, an optional mode argument can be specified:
cpupm enable mode
Acceptable mode values and their meanings are:
If supported by the platform, a cpu_deep_idle entry can be used to enable or disable automatic use of power saving cpu idle states. The format of the cpu_deep_idle entry is:
Acceptable values for behavior are:
Once every device is at its lowest possible power state, additional power savings can be obtained by putting the system into a sleep state (if the platform hardware is capable of doing so).
Acceptable behavior values are:
The format of the autoS3 entry is autoS3 behavior.
Acceptable behavior values are:
The system can be configured to do an automatic shutdown (autoshutdown) using the suspend-resume feature by an entry of the following form:
autoshutdown idle_time start_time finish_time behavior
idle_time specifies the time in minutes that system must have been idle before it is automatically shutdown. System idleness is determined by the inactivity of the system and can be configured as discussed below.
start_time and finish_time (each in hh:mm) specify the time period during which the system can be automatically shutdown. These times are measured from the start of the day (12:00 a.m.). If the finish_time is less than or equal to the start_time, the period span from midnight to the finish_time and from the start_time to the following midnight. To specify continuous operation, the finish_time can be set equal to the start_time.
Acceptable behavior values are described as follows:
You can use the following format to configure the system's notion of idleness:
Where idleness_parameter can be:
There is no default idlecheck entry.
When the system is suspended, the current system state is saved on the disk in a statefile. An entry of following form can be used to change the location of statefile:
where pathname identifies a block special file, for example, /dev/dsk/c1t0d0s2, or is the absolute pathname of a local ufs file. If the pathname specifies a block special file, it can be a symbolic link as long as it does not have a file system mounted on it. If pathname specifies a local ufs file, it cannot be a symbolic link. If the file does not exist, it is created during the suspend operation. All the directory components of the path must already exist.
The actual size of statefile depends on a variety of factors, including the size of system memory, the number of loadable drivers/modules in use, the number and type of processes running, and the amount of user memory that has been locked down. It is recommended that statefile be placed on a file system with at least 10 Mbytes of free space. In case there is no statefile entry at boot time, an appropriate new entry is automatically created by the system.
To disable automatic device Power Management, change the following line in the /etc/power.conf file
Then run pmconfig or reboot. See pmconfig(8) for more information.
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
Writing Device Drivers
SPARC desktop models first shipped after July 1, 1999 comply with the United States Environmental Protection Agency's Energy Star Memorandum of Understanding #3 guidelines and have autoshutdown disabled by default, with autopm enabled after 30 minutes of idleness. This is achieved by interpreting default keyword of autopm entry behavior as enabled for these machines. User is not prompted to confirm this default behavior.
To determine the version of the EPA's Energy Star Memorandum applicable to your machine, use:
prtconf -pv | grep -i energystar
Absence of a property indicates no Energy Star guidelines are applicable to your machine.
System Power Management (suspend-resume) is currently supported only on a limited set of hardware platforms.
Sun X86 desktop models first shipped after July 1, 1999 fall within United States Environmental Protection Agency's Energy Star Memorandum of Understanding #3 guidelines and have autopm and autoS3 enabled by default, with entry into S3 after 30 minutes of idleness. This is achieved by interpreting the default keyword of the autopm and autoS3 behaviors as enabled for these machines. You are not prompted to confirm the default behavior. On all other X86 systems, the autopm and autoS3 default keywords are interpreted as disable.
|June 20, 2021||OmniOS|