Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
power.conf(4)			 File Formats			 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 configuration pro-
       gram 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 parameters.

       Power Management	addresses two specific management  scenarios:  manage-
       ment of individual devices and management of the	whole system. An indi-
       vidual device is	power managed if a device supports multiple power lev-
       els  and	if the device driver uses Power	Management interfaces provided
       by the kernel 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 sec-
       tion  of	 this manual page. If the device driver	uses new automatic de-
       vice Power Management interfaces, the device is controlled by  the  en-
       tries  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	 corresponding	device
       Power  Management entries in power.conf file that were supported	in So-
       laris 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	depen-
       dent_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  preceded	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.  de-
       vice_name  is either a pathname specifying the device special 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 component of the pathname
       does not	need to	be specified.

       The threshold field is used to configure	the  power  manageable	compo-
       nents  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	speci-
       fies 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 previously have been  configured	before
       it can be used in dependent_upon	list. This field should	only list log-
       ical dependents for this	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 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 in-
       terfaces	 (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	imple-
       ment multiple components,  each	component  is  power-managed  indepen-
       dently.

       Default	thresholds  for	 components of automatically power managed de-
       vices are computed by the Power Management framework based on the  sys-
       tem  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:

       system-threshold	    threshold

       system-threshold	   always-on

       where threshold	is the value  of  the  system  idleness	 threshold  in
       hours,  minutes	or  seconds  as	indicated by a trailing	h, m or	s (de-
       faulting	to seconds if only a number is given). If always-on is	speci-
       fied, 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 spe-
       cific device. For example, /pci@8,600000/scsi@4/ssd@w210000203700c3ee,0
       specifies  the  physical	 path of a disk. A symbolic link into the /de-
       vices tree  (for	 example  /dev/dsk/c1t1d0s0)  is  also	accepted.  The
       thresholds  apply (or keeping the device	always on applies) to the spe-
       cific 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 de-
       fault to	seconds) to spend idle at the corresponding power level	before
       power will be reduced to	the next lower level of	that component.	Paren-
       theses are used to group	 thresholds  per  component,  with  the	 first
       (leftmost) group	being applied to component 0, the next to component 1,
       etc. 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  ex-
       ported  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 mes-
       sage will be printed and	the entry will be 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 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	compo-
       nents 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	effec-
       tive 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 de-
       pendents	 for  the  device. A logical dependent is a device that	is not
       physically connected to the power managed device	(for example, the dis-
       play  and  the keyboard). Physical dependents are automatically consid-
       ered 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 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  re-
       movable-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 Memorandum of	Understanding #3 will have au-
	     tomatic device Power Management enabled, and all others will not.
	     See the NOTES section of this manual page for more	information.

       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 en-
       tire system using the suspend-resume feature. When the system  is  sus-
       pended, 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 ( autoshut-
       down) 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 system	and can	be configured as discussed be-
       low.

       start_time and finish_time (each	in hh:mm) specify the time period dur-
       ing  which  the	system	may 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_timemay 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 fin-
	     ish_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 Memorandum of	Understanding #2 will have au-
	     tomatic  shutdown enabled (as if behavior field were set to shut-
	     down), 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 characters 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  pro-
	     vided.

       loadaverage
	     If	 the  idleness_parameter  is loadaverage, the (floating	point)
	     value field will be interpreted as	the maximum load average  that
	     can  be  seen  while  still  allowing 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 per-
	     form by the system	while still allowing the system	to be  consid-
	     ered 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	 path-
	     name  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 system 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 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.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       +---------------------------+-------------------------------+
       |      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  Enviromental  Protection
       Agency's	Energy Star Memorandum of Understanding	#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 confirm  this  de-
       fault  behavior	at system installation reboot, or during the first re-
       boot 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  de-
       fault,  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 de-
       fault 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 applica-
       ble to your machine.

       System Power Management ( suspend-resume) is currently  supported  only
       on  a  limited  set  of hardware	platforms. Please see the book Solaris
       Common Desktop Environment: User's Guidefor a complete  list  of	 plat-
       forms that support system Power Management.  See	uname(2) to programat-
       ically determine	if the machine supports	suspend-resume.

SunOS 5.9			  15 Jun 2001			 power.conf(4)

NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | SEE ALSO | NOTES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=power.conf&sektion=4&manpath=SunOS+5.9>

home | help