power.conf(4)
NAME
power.conf - Power management configuration information file
SYNOPSIS
/etc/power.conf
DESCRIPTION
The power.conf file is used by the power management confi-
guration program pmconfig(1M), to initialize the settings
for power management. If you make changes to this file, you
must run pmconfig(1M) manually for the changes to take
effect.
The dtpower(1M) GUI allows the configuration of a subset of
parameters allowed by this file. For ease-of-use, it is
recommended that you use dtpower(1M) to configure the param-
eters. For information on disabling power management, see
the EXAMPLES section of this manual page
Power management addresses two specific management
scenarios: management of individual devices and management
of the whole system. An individual device is power managed
if a device supports multiple power levels and if the device
driver uses power management interfaces provided by the ker-
nel to save device power when the device is idle. If the
driver uses the original power management interfaces, the
device is controlled by the entries described in the Device
Power Management section of this manual page. If the device
driver uses new automatic device power management inter-
faces, the device is controlled by the entries described in
the Automatic Device Power Management section of this manual
page.
To determine if the device driver supports original power
management interfaces, contact the device vendor. To find
out if the device driver supports the new automatic device
power management interfaces, look for pm-components property
(pm-components(9P)) under the device name from the output of
prtconf -v command (prtconf(1M)).
The original power management interfaces and the correspond-
ing device power management entries in power.conf file that
were supported in Solaris 7 and earlier releases are now
obsolete. Support for them will be removed in a future
release.
All entries in the power.conf file are processed in the
order displayed in the file.
Device Power Management
Device power management entries are now obsolete and support
for them will be removed in a future release. If a device
supports original power management interfaces, it needs to
be explicitly configured for power management using an entry
of the form shown below. A device will not be power managed
if there is no entry for the device. Be sure you fully
understand the power management framework before you attempt
to modify device power management entries.
Device power management entries consist of line-by-line
listings of the devices to be configured. Each line is of
the form:
device_name threshold...dependent_upon...
The fields must be in the order shown above. Each line must
contain a device_name field and a threshold field; it may
also contain a dependent_upon field. Fields and sub-fields
are separated by white space (tabs or spaces). A line may
be more than 80 characters. If a newline character is pre-
ceded by a backslash () it will be treated as white space.
Comment lines must begin with a hash character (#).
The device_name field specifies the device to be configured.
device_name is either a pathname specifying the device spe-
cial file or a relative pathname containing the name of the
device special file. For the latter format, you can avoid
using the full pathname by omitting the pathname component
that specifies the parent devices. This includes the leading
'/'. Using the relative pathname format, the first device
found with a full pathname containing device_name as its
tail is matched. In either case, the leading /devices com-
ponent of the pathname does not need to be specified.
The threshold field is used to configure the power manage-
able components of a device. These components represent
entities within a device that may be power-managed
separately. This field may contain as many integer values as
the device has components. Each threshold time specifies the
idle time in seconds before the respective component may be
powered down. If there are fewer component threshold times
than device components, the remaining components are not
power managed. Use a value of -1 to explicitly disable
power-down for a component. At least one component threshold
must be specified per device (in the file).
The dependent_upon field contains a list of devices that
must be idle and powered-down before the dependent device in
device_name field can be powered down. A device must previ-
ously have been configured before it can be used in
dependent_upon list. This field should only list logical
dependents for this device. A logical dependent is a device
that is not physically connected to the power managed dev-
ice, for example, the display and the keyboard. Physical
dependents are automatically considered and do not need to
be included.
A device power management entry is only effective if there
is no user process controlling the device directly. For
example, X Window systems directly control framebuffers and
entries in this file are effective only when X Windows are
not running.
Automatic Device Power Management
Devices whose drivers use the new automatic device power
management interfaces (as evident by existence of pm-
components(9P) property) are automatically power managed if
enabled by the autopm entry described below.
When a component has been idle at a given power level for
its threshold time, the power level of the component will be
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 frame-
work 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 follow-
ing entries:
system-threshold threshold
system-threshold always-on
where threshold is the value of the system idleness thres-
hold 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 will
be left at full power.
To override the default device component thresholds assigned
by the power management framework, a device-thresholds entry
may 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 ...) ...
or
device-thresholds phys_path threshold
or
device-thresholds phys_path always-on
where phys_path specifies the physical path (libdevinfo(3))
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 will be 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 com-
ponents 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 will
be printed and the entry will be ignored.
For example, assume a device called xfb exports the com-
ponents 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
Suspendin 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 will be 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
may be among a device's components, the device may actually
be powered down sooner than the specified threshold, but
will not 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 Window systems directly control frame buffers and
the entries in this file are effective only when X Windows
are not running.
Dependencies among devices may also be defined. A device
depends upon another if none of its components may have
their power levels reduced unless all components of the
other device are powered off. A dependency may 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 physi-
cally 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 arbi-
trary group of devices can be made dependent upon another
device by specifying a property dependency using the follow-
ing syntax:
device-dependency-property property phys_path [phys_path ...]
where each device that exports the property property will be
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:
# 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
ensures that every device that exports the boolean property
named removable-media will be kept up when the console
framebuffer is up. See removable-media(9P).
An autopm entry may be used to enable or disable automatic
device power management on a system-wide basis. The format
of the autopm entry is:
autopmvbehavior
Acceptable behavior values and their meanings are:
default
The behavior of the system will depend upon its model.
Desktop models that fall under the United States
Environmental Protection Agency's Energy Star Memoran-
dum of Understanding #3 will have automatic device
power management enabled, and all others will not. See
the NOTES section of this manual page for more infor-
mation.
enable
Automatic device power management will be started when
this entry is encountered.
disable
Automatic device power management will be stopped when
this entry is encountered.
System Power Management
The system power management entries control power management
of the entire system using the suspend-resume feature. When
the system is suspended, the complete current state is saved
on the disk before power is removed. On reboot, the system
automatically starts a resume operation and the system is
restored to the state it was in prior to suspend.
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 will be automatically shutdown.
System idleness is determined by the inactivity of the sys-
tem and can be configured as discussed below.
start_time and finish_time (each in hh:mm) specify the time
period during which the system may be automatically shut-
down. 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 mid-
night. To specify continuous operation, the finish_time may
be set equal to the start_time.
Acceptable behavior values and their meanings are:
shutdown
The system will be shut down automatically when it has
been idle for the number of minutes specified in the
idle_time value and the time of day falls between the
start_time and finish_time values.
noshutdown
The system is never shut down automatically.
autowakeup
If the hardware has the capability to do autowakeup,
the system is shut down as if the value were shutdown
and the system will be restarted automatically the
next time the time of day equals finish_time.
default
The behavior of the system will depend upon its model.
Desktop models that fall under the United States
Enviromental Protection Agency's Energy Star Memoran-
dum of Understanding #2 will have automatic shutdown
enabled, as if behavior field were set to shutdown,
and all others will not. See NOTES.
unconfigured
The system will not be shut down automatically. If the
system has just been installed or upgraded, the value
of this field will be changed upon the next reboot.
You can use the following format to configure the system's
notion of idleness:
idleness_parameter value
Where idleness_parameter can be:
ttychars
If the idleness_parameter is ttychars, the value field
will be interpreted as the maximum number of tty char-
acters that can pass through the ldterm module while
still allowing the system to be considered idle. This
value defaults to 0 if no entry is provided.
loadaverage
If the idleness_parameter is loadaverage, the (float-
ing point) value field will be interpreted as the max-
imum load average that can be seen while still allow-
ing the system to be considered idle. This value
defaults to 0.04 if no entry is provided.
diskreads
If the idleness_parameter is diskreads, the value
field will be interpreted as the maximum number of
disk reads that can be perform by the system while
still allowing the system to be considered idle. This
value defaults to 0 if no entry is provided.
nfsreqs
If the idleness_parameter is nfsreqs, the value field
will be interpreted as the maximum number of NFS
requests that can be sent or received by the system
while still allowing the system to be considered idle.
Null requests, access requests, and getattr requests
are excluded from this count. This value defaults to 0
if no entry is provided.
idlecheck
If the idleness_parameter is idlecheck, the value must
be pathname of a program to be executed to determine
if the system is idle. If autoshutdown is enabled and
the console keyboard, mouse, tty, CPU (as indicated by
load average), network (as measured by NFS requests)
and disk (as measured by read activity) have been idle
for the amount of time specified in the autoshutdown
entry specified above, and the time of day falls
between the start and finish times, then this program
will be executed to check for other idleness criteria.
The value of the idle time specified in the above
autoshutdown entry will be passed to the program in
the environment variable PM_IDLETIME. The process
must terminate with an exit code that represents the
number of minutes that the process considers the sys-
tem to have been idle.
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:
statefile pathname
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 will be 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 fac-
tors, 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 appropri-
ate new entry is automatically created by the system.
EXAMPLES
Example 1: Disabling Automatic Device Power Management
To disable automatic device power management, change the
following line in the /etc/power.conf file
autopm default
to read:
autopm disable
Then run pmconfig or reboot. See pmconfig(1M) for more
information.
You can also use dtpower to disable automatic device power
management. See dtpower(1M) for more information.
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|___________________________|_______________________________|
| Availability | SUNWpmr |
|___________________________|_______________________________|
| Interface stability | Evolving (Interfaces under|
| | DEVICE POWER MANAGEMENT are|
| | obsolete.) |
|___________________________|_______________________________|
SEE ALSO
pmconfig(1M), powerd(1M), sys-unconfig(1M), uadmin(2),
attributes(5), cpr(7), ldterm(7M), pm(7D), pm-
components(9P), removable-media(9P)
Writing Device Drivers
Solaris Common Desktop Environment: User's Guide
NOTES
SPARC desktop models first shipped after October 1, 1995 and
before July 1, 1999 comply with the United States Enviromen-
tal Protection Agency's Energy Star Memorandum of Under-
standing #2 guidelines and have autoshutdownenabled by
default after 30 minutes of system idleness. This is
achieved by default keyword of autoshutdown entry behave as
shutdown for these machines. The user is prompted to con-
firm this default behavior at system installation reboot, or
during the first reboot after the system is unconfigured by
sys-unconfig(1M).
SPARC desktop models first shipped after July 1, 1999 comply
with the United States Enviromental Protection Agency's
Energy Star Memorandum of Understanding #3 guidelines and
have autoshutdowndisabled by default, with autopm enabled
after 30 minutes of idleness. This is achieved by interpret-
ing 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 sup-
ported only on a limited set of hardware platforms. Please
see the book Solaris Common Desktop Environment: User's
Guidefor a complete list of platforms that support system
power management. See uname(2) to programatically determine
if the machine supports suspend-resume.
Man(1) output converted with
man2html