1power.conf(4) File Formats power.conf(4)
2
6 power.conf - Power Management configuration information file
7
9 /etc/power.conf
10
13 The power.conf file is used by the Power Management configuration pro‐
14 gram pmconfig(1M), to initialize the settings for Power Management. If
15 you make changes to this file, you must run pmconfig(1M) manually for
16 the changes to take effect.
17 The dtpower(1M) GUI allows the configuration of a subset of parameters
20 allowed by this file. For ease-of-use, it is recommended that you use
21 dtpower(1M) to configure the parameters. See the EXAMPLES section for
22 information on disabling Power Management.
23 Power Management addresses two specific management scenarios: manage‐
26 ment of individual devices and management of the whole system. An indi‐
27 vidual device is power managed if the device supports multiple power
28 levels and if the device driver uses Power Management interfaces pro‐
29 vided by the kernel to save device power when the device is idle.
30 All entries in the power.conf file are processed in the order that they
33 occur in the file.
34 Automatic Device Power Management
36 Devices with drivers that use the automatic device Power Management
37 interfaces are automatically power managed if the autopm entry is
38 enabled. The autopm entry is described near the end of this section.
39 The pm-components property describes the Power Management model of a
40 device driver to the Power Management framework. See pm-components(9P)
41 for more information.
42 When a component has been idle at a given power level for its threshold
45 time, the power level of the component is reduced to the next lower
46 power level of that component, if any. For devices which implement mul‐
47 tiple components, each component is power-managed independently.
48 Default thresholds for components of automatically power managed
51 devices are computed by the Power Management framework based on the
52 system idleness threshold. By default, all components of the device are
53 powered off if they have all been idle for the system's idleness
54 threshold. The default system idleness threshold is determined by the
55 applicable United States Environmental Protection Agency's (EPA) Energy
56 Star Memorandum of Understanding. See the NOTES section of this manual
57 page for more information.
58 To set the system idleness threshold, use one of the following entries:
61 system-threshold threshold
63 system-threshold always-on
66 where threshold is the value of the system idleness threshold in hours,
70 minutes or seconds as indicated by a trailing h, m or s (defaulting to
71 seconds if only a number is given). If always-on is specified, then by
72 default, all devices are left at full power.
73 The system-threshold entry is applicable to CPU Power Management only
76 when CPU Power Management has been configured to operate in poll-mode,
77 which is expressed through the cpupm keyword.
78 If a system has power manageable CPUs, these can be managed indepen‐
81 dently of the system idleness threshold by using one of the following
82 entries:
83 cpu-threshold threshold
85 cpu-threshold always-on
88 where threshold is the value of the CPU idleness threshold in hours,
92 minutes or seconds as indicated by a trailing h, m or s (defaulting to
93 seconds if only a number is given). If always-on is specified, then by
94 default, all CPUs are left at full power.
95 The cpu-threshold keyword is used only when CPU Power Management has
98 been configured to operate in poll-mode, which is expressed through the
99 cpupm keyword.
100 If no cpu-threshold entry is specified, then the system idleness
103 threshold is used.
104 To override the default device component thresholds assigned by the
107 Power Management framework, a device-thresholds entry can be used. A
108 device-thresholds entry sets thresholds for a specific automatically
109 power-managed device or disables automatic Power Management for the
110 specific device.
111 A device-thresholds entry has the form:
114 device-thresholds phys_path (threshold ...) ...
116 or
120 device-thresholds phys_path threshold
122 or
126 device-thresholds phys_path always-on
128 where phys_path specifies the physical path (libdevinfo(3LIB)) of a
132 specific device. For example,
133 /pci@8,600000/scsi@4/ssd@w210000203700c3ee,0 specifies the physical
134 path of a disk. A symbolic link into the /devices tree, for example
135 /dev/dsk/c1t1d0s0, is also accepted. The thresholds apply (or keeping
136 the device always on applies) to the specific device only.
137 In the first form above, each threshold value represents the number of
140 hours, minutes or seconds, depending on a trailing h, m or s with a
141 default to seconds, to spend idle at the corresponding power level
142 before power is reduced to the next lower level of that component.
143 Parentheses are used to group thresholds per component, with the first
144 (leftmost) group being applied to component 0, the next to component 1,
145 and the like. Within a group, the last (rightmost) number represents
146 the time to be idle in the highest power level of the component before
147 going to the next-to-highest level, while the first (leftmost) number
148 represents the time to be idle in the next-to-lowest power level before
149 going to the lowest power level.
150 If the number of groups does not match the number of components
153 exported by the device (by means of pm-components(9P) property), or the
154 number of thresholds in a group is not one less than the number of
155 power levels the corresponding component supports, then an error mes‐
156 sage is printed and the entry is ignored.
157 For example, assume a device called xfb exports the components Frame
160 Buffer and Monitor. Component Frame Buffer has two power levels: Off
161 and On. Component Monitor has four power levels: Off, Suspend, Standby,
162 and On.
163 The following device-thresholds entry:
166 device-thresholds /pci@f0000/xfb@0 [4m(0) (3m 5m 15m)
168 would set the threshold time for the Monitor component of the specific
172 xfb card to go from On to Standby in 15 minutes, the threshold for Mon‐
173 itor to go from Standby to Suspendin 5 minutes, and the threshold for
174 Monitor to go from Suspend to Off in 3 minutes. The threshold for Frame
175 Buffer to go from On to Off is 0 seconds.
176 In the second form above, where a single threshold value is specified
179 without parentheses, the threshold value represents a maximum overall
180 time within which the entire device should be powered down if it is
181 idle. Because the system does not know about any internal dependencies
182 there can be among a device's components, the device can actually be
183 powered down sooner than the specified threshold, but does take longer
184 than the specified threshold, provided that all device components are
185 idle.
186 In the third form above, all components of the device are left at full
189 power.
190 Device Power Management entries are only effective if there is no user
193 process controlling the device directly. For example, X Windows systems
194 directly control frame buffers. The entries in the power.conf file are
195 effective only when X Windows is not running.
196 Dependencies among devices can also be defined. A device depends upon
199 another if none of its components might have their power levels reduced
200 unless all components of the other device are powered off. A dependency
201 can be indicated by an entry of the form:
202 device-dependency dependent_phys_path phys_path [ phys_path ... ]
204 where dependent_phys_path is the path name (as above) of the device
208 that is kept up by the others, and the phys_path entries specify the
209 devices that keep it up. A symbolic link into the /devices tree, such
210 as /dev/fb, is also accepted. This entry is needed only for logical
211 dependents for the device. A logical dependent is a device that is not
212 physically connected to the power managed device (for example, the dis‐
213 play and the keyboard). Physical dependents are automatically consid‐
214 ered and need not be included.
215 In addition to listing dependents by physical path, an arbitrary group
218 of devices can be made dependent upon another device by specifying a
219 property dependency using the following syntax:
220 device-dependency-property property phys_path [phys_path ...]
222 where each device that exports the property property is kept up by the
227 devices named by phys_path(s). A symbolic link into the /devices tree
228 (such as /dev/fb) is accepted as well as a pathname for phys_path.
229 For example, the following entry ensures that every device that exports
232 the boolean property named removable-media is kept up when the console
233 framebuffer is up. See removable-media(9P).
234 # This entry keeps removable media from being powered down unless the
236 # console framebuffer and monitor are powered down
237 # (See removable-media(9P))
238 #
239 device-dependency-property removable-media /dev/fb
240 An autopm entry can be used to enable or disable automatic device Power
244 Management on a system-wide basis. The format of the autopm entry is:
245 autopm behavior
247 Acceptable behavior values are described as follows:
251 default The behavior of the system depends upon its model. Desktop
253 models that fall under the United States Environmental Pro‐
254 tection Agency's Energy Star Memorandum of Understanding #3
255 have automatic device Power Management enabled, and all oth‐
256 ers do not. See the NOTES section of this manual page for
257 more information.
258 enable Automatic device Power Management is started when this entry
261 is encountered.
262 disable Automatic device Power Management is stopped when this entry
265 is encountered.
266 A cpupm entry can be used to enable or disable Power Management of CPUs
270 on a system-wide basis, independent of autopm. The format of the cpupm
271 entry is:
272 cpupm behavior
274 Acceptable behavior values and their meanings are :
278 enable CPU Power Management is started when this entry is encoun‐
280 tered.
281 Where the behavior is enable, an optional mode argument can
283 be specified:
284 cpupm enable mode
286 Acceptable mode values and their meanings are:
288 event-mode CPU power state transitions is driven by
290 thread scheduler/dispatcher events. The cpu-
291 threshold, and system-threshold keywords are
292 not used for CPUs in this mode.
293 poll-mode The Power Management framework polls the idle‐
296 ness of the system's CPUs, and manages their
297 power once idle for the period of time speci‐
298 fied by either the system-threshold or cpu-
299 threshold.
300 disable CPU Power Management is stopped when this entry is encoun‐
304 tered.
305 If supported by the platform, a cpu_deep_idle entry can be used to
309 enable or disable automatic use of power saving cpu idle states. The
310 format of the cpu_deep_idle entry is:
311 cpu_deep_idle behavior
313 Acceptable values for behavior are:
318 default Advanced cpu idle power saving features are enabled on hard‐
320 ware which supports it. On X86 systems this can translate to
321 the use of ACPI C-States beyond C1.
322 enable Enables the system to automatically use idle cpu power sav‐
325 ing features.
326 disable The system does not automatically use idle cpu power saving
329 features. This option can be used when maximum performance
330 is required at the expense of power.
331 absent It the cpu_deep_idle keyword is absent from power.conf the
334 behavior is the same as the default case.
335 Once every device is at its lowest possible power state, additional
339 power savings can be obtained by putting the system into a sleep state
340 (if the platform hardware is capable of doing so).
341 S3 Support
343 Because of reliability problems encountered in BIOS implementations of
344 X86 systems not produced by Sun Microsystems, by default, only X86
345 workstation products produced by Sun are considered to support S3 (sus‐
346 pend to RAM). To override this default, an S3-support entry (of the
347 format S3-support behavior) can be used to indicate if the system sup‐
348 ports S3.
349 Acceptable behavior values are:
352 enable The system supports entry into S3 state. If the BIOS of a
354 system enabled using an S3-support enable entry does not
355 support entry into S3, the attempt fails and the system
356 returns to normal operation. If support for S3 in the BIOS
357 of a system enabled via an S3-support entry contains bugs,
358 the system can be unable to enter S3 or resume successfully,
359 so use this entry with caution.
360 disable The system does not support entry into S3 state.
363 Automatic Entry Into S3
366 If supported by your platform, an autoS3 entry can be used to enable or
367 disable automatic entry into the S3 state. When in the S3 state, the
368 power button, keyboard and mouse activity or network traffic (depending
369 upon the capabilities of the platform hardware) can wake the system,
370 returning it to the state it was in upon entry to the S3 state. If the
371 platform doesn't support S3, the entry has no effect.
372 The format of the autoS3 entry is autoS3 behavior.
375 Acceptable behavior values are:
378 default System behavior depends upon model. Sun X86 desktop and
380 workstation models that fall under the United States Envi‐
381 ronmental Protection Agency's Energy Star Memorandum of
382 Understanding #3 have automatic entry into the S3 state
383 enabled. Non-Sun systems do not. See NOTES for more informa‐
384 tion.
385 enable Enables the system to automatically enter the S3 state if
388 autopm is enabled and every device is at its lowest power
389 state.
390 disable The system does not automatically enter the S3 state.
393 System Power Management
396 The system Power Management entries control Power Management of the
397 entire system using the suspend-resume feature. When the system is sus‐
398 pended, the complete current state is saved on the disk before power is
399 removed. On reboot, the system automatically starts a resume operation
400 and the system is restored to the state it was in prior to suspend.
401 The system can be configured to do an automatic shutdown (autoshutdown)
404 using the suspend-resume feature by an entry of the following form:
405 autoshutdown idle_time start_time finish_time behavior
407 idle_time specifies the time in minutes that system must have been idle
411 before it is automatically shutdown. System idleness is determined by
412 the inactivity of the system and can be configured as discussed below.
413 start_time and finish_time (each in hh:mm) specify the time period dur‐
416 ing which the system can be automatically shutdown. These times are
417 measured from the start of the day (12:00 a.m.). If the finish_time is
418 less than or equal to the start_time, the period span from midnight to
419 the finish_time and from the start_time to the following midnight. To
420 specify continuous operation, the finish_time can be set equal to the
421 start_time.
422 Acceptable behavior values are described as follows:
425 shutdown The system is shut down automatically when it has been
427 idle for the number of minutes specified in the
428 idle_time value and the time of day falls between the
429 start_time and finish_time values.
430 noshutdown The system is never shut down automatically.
433 autowakeup If the hardware has the capability to do autowakeup,
436 the system is shut down as if the value were shutdown
437 and the system is restarted automatically the next time
438 the time of day equals finish_time.
439 default The behavior of the system depends upon its model.
442 Desktop models that fall under the United States Envi‐
443 ronmental Protection Agency's Energy Star Memorandum of
444 Understanding #2 have automatic shutdown enabled, as if
445 behavior field were set to shutdown, and all others do
446 not. See NOTES.
447 unconfigured The system does not be shut down automatically. If the
450 system has just been installed or upgraded, the value
451 of this field is changed upon the next reboot.
452 You can use the following format to configure the system's notion of
456 idleness:
457 idleness_parameter value
460 Where idleness_parameter can be:
463 ttychars If the idleness_parameter is ttychars, the value field
465 is interpreted as the maximum number of tty characters
466 that can pass through the ldterm module while still
467 allowing the system to be considered idle. This value
468 defaults to 0 if no entry is provided.
469 loadaverage If the idleness_parameter is loadaverage, the (floating
472 point) value field is interpreted as the maximum load
473 average that can be seen while still allowing the system
474 to be considered idle. This value defaults to 0.04 if no
475 entry is provided.
476 diskreads If the idleness_parameter is diskreads, the value field
479 is interpreted as the maximum number of disk reads that
480 can be perform by the system while still allowing the
481 system to be considered idle. This value defaults to 0
482 if no entry is provided.
483 nfsreqs If the idleness_parameter is nfsreqs, the value field is
486 interpreted as the maximum number of NFS requests that
487 can be sent or received by the system while still allow‐
488 ing the system to be considered idle. Null requests,
489 access requests, and getattr requests are excluded from
490 this count. This value defaults to 0 if no entry is pro‐
491 vided.
492 idlecheck If the idleness_parameter is idlecheck, the value must
495 be pathname of a program to be executed to determine if
496 the system is idle. If autoshutdown is enabled and the
497 console keyboard, mouse, tty, CPU (as indicated by load
498 average), network (as measured by NFS requests) and disk
499 (as measured by read activity) have been idle for the
500 amount of time specified in the autoshutdown entry spec‐
501 ified above, and the time of day falls between the start
502 and finish times, then this program is executed to check
503 for other idleness criteria. The value of the idle time
504 specified in the above autoshutdown entry is passed to
505 the program in the environment variable PM_IDLETIME. The
506 process must terminate with an exit code that represents
507 the number of minutes that the process considers the
508 system to have been idle.
509 There is no default idlecheck entry.
511 When the system is suspended, the current system state is saved on the
515 disk in a statefile. An entry of following form can be used to change
516 the location of statefile:
517 statefile pathname
519 where pathname identifies a block special file, for example,
523 /dev/dsk/c1t0d0s2, or is the absolute pathname of a local ufs file. If
524 the pathname specifies a block special file, it can be a symbolic link
525 as long as it does not have a file system mounted on it. If pathname
526 specifies a local ufs file, it cannot be a symbolic link. If the file
527 does not exist, it is created during the suspend operation. All the
528 directory components of the path must already exist.
529 The actual size of statefile depends on a variety of factors, including
532 the size of system memory, the number of loadable drivers/modules in
533 use, the number and type of processes running, and the amount of user
534 memory that has been locked down. It is recommended that statefile be
535 placed on a file system with at least 10 Mbytes of free space. In case
536 there is no statefile entry at boot time, an appropriate new entry is
537 automatically created by the system.
538
540 Example 1 Disabling Automatic Device Power Management
541 To disable automatic device Power Management, change the following line
544 in the /etc/power.conf file
545 autopm default
548 to read:
552 autopm disable
555 Then run pmconfig or reboot. See pmconfig(1M) for more information.
559 You can also use dtpower to disable automatic device Power Management.
563 See dtpower(1M) for more information.
564
567 See attributes(5) for descriptions of the following attributes:
568 ┌─────────────────────────────┬─────────────────────────────┐
573 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
574 ├─────────────────────────────┼─────────────────────────────┤
575 │Availability │SUNWpmr │
576 ├─────────────────────────────┼─────────────────────────────┤
577 │Interface stability │Committed │
578 └─────────────────────────────┴─────────────────────────────┘
579
581 pmconfig(1M), powerd(1M), sys-unconfig(1M), uadmin(2), libdev‐
582 info(3LIB), attributes(5), cpr(7), ldterm(7M), pm(7D), pm-compo‐
583 nents(9P), removable-media(9P)
584 Writing Device Drivers
587 Solaris Common Desktop Environment: User's Guide
590
592 SPARC desktop models first shipped after October 1, 1995 and before
593 July 1, 1999 comply with the United States Environmental Protection
594 Agency's Energy Star Memorandum of Understanding #2 guidelines and have
595 autoshutdown enabled by default after 30 minutes of system idleness.
596 This is achieved by default keyword of autoshutdown entry behave as
597 shutdown for these machines. The user is prompted to confirm this
598 default behavior at system installation reboot, or during the first
599 reboot after the system is unconfigured by sys-unconfig(1M).
600 SPARC desktop models first shipped after July 1, 1999 comply with the
603 United States Environmental Protection Agency's Energy Star Memorandum
604 of Understanding #3 guidelines and have autoshutdown disabled by
605 default, with autopm enabled after 30 minutes of idleness. This is
606 achieved by interpreting default keyword of autopm entry behavior as
607 enabled for these machines. User is not prompted to confirm this
608 default behavior.
609 To determine the version of the EPA's Energy Star Memorandum applicable
612 to your machine, use:
613 prtconf -pv | grep -i energystar
615 Absence of a property indicates no Energy Star guidelines are applica‐
619 ble to your machine.
620 System Power Management ( suspend-resume) is currently supported only
623 on a limited set of hardware platforms. See the Solaris Common Desktop
624 Environment: User's Guide for a complete list of platforms that support
625 system Power Management. See uname(2) to programmatically determine if
626 the machine supports suspend-resume.
627 Sun X86 desktop models first shipped after July 1, 1999 fall within
630 United States Environmental Protection Agency's Energy Star Memorandum
631 of Understanding #3 guidelines and have autopm and autoS3 enabled by
632 default, with entry into S3 after 30 minutes of idleness. This is
633 achieved by interpreting the default keyword of the autopm and autoS3
634 behaviors as enabled for these machines. You are not prompted to con‐
635 firm the default behavior. On all other X86 systems, the autopm and
636 autoS3 default keywords are interpreted as disable.
637SunOS 5.11 27 Feb 2009 power.conf(4)