Note: This section applies to AIX Version 4 systems.
AIX drivers has been updated to provide for Power Management (PM) support. PM is a technique that enables hardware and software to minimize system power consumption. PM is generally only important to low-end models, such as Notebooks and systems operating on battery.
When Power Management is enabled, the system enters a power-saving mode under a number of conditions including the expiration of the idle timer, a direct command from the user, a low battery, or the closing of the Notebook lid. PM state transitions include: enable, standby, suspend, hibernation, and shutdown. Each transition implies further decreasing the power supply to the various system components. Only the suspend, hibernation, and shutdown states have any impact on X.25 connections.
Refer to "Management Power Management" in AIX Version 4.3 System Management Guide: Operating System and Devices for more detailed information on Power Management and its configuration and function.
From an X.25 standpoint, bringing a system to the suspend, hibernation, or shutdown states results in loss of power to the adapters. All network connections are lost. Externally, this can be viewed as pulling the physical connection (cable), since there is a complete loss of signal power at the physical layer.
Since all signals are dropped at the physical layer, there is no opportunity for the local DTE packet layer to send out clear requests to the DCE packet layer. Similarly, the frame layer does not go through the usual DISC/UA sequence prior to bringing down the link level. All X.25 connections remain down until the system is re-enabled.
Once power is restored, all X.25 physical connections previously up are restored. Two possible exceptions are dial-up connections and ports controlled directly by DLPI applications. For dial-up, even though the physical layer is reinitialized for two-way activation, these connections are only physically reconnected when there is user activity, such as an outgoing call request or an incoming call. Likewise, for DLPI ports, it is necessary for the applications to reconnect (DL_CONNECT request) to activate the port.
Note: Restoring an X.25 connection refers to bringing up the physical, frame, and packet layers between the local DTE and DCE. Switched virtual circuits (SVCs) that were active before the power loss have been cleared. Permanent virtual circuits (PVCs) have been reset. It is up to the corresponding applications to re-establish the SVCs and properly resynchronize the PVCs.
A system shutdown impacts X.25 applications differently than either a suspend or hibernation transition. In the case of a shutdown, all user applications are terminated. With a system shutdown, no attempt is made to preserve the current user state before powering off. On bring-up, those ports and interfaces defined in the ODM are newly configured. All X.25 user application need to be restarted after power-on.
In the case of the suspend and hibernation states, there is an attempt to preserve as much of the current system state as possible in order to make the off-on cycle transparent to user applications. All user applications remain active. For X.25, however, the network connections have been physically lost and restarted. Losing the network connections directly impacts X.25 applications. The Power Management suspend and hibernation power-off and power-on cycles are generally not completely transparent.
The following highlights the expected behaviors during a PM suspend or hibernation power-off and power-on cycle for each of the programming interfaces:
|Receives a DL_DISCONNECT indication. It is up to the DLPI application to properly handle the indication. The port is not activated until a new DL_CONNECT request is issued by the application. It is not necessary to re-bind to the port since all the DL_BINDs are maintained. For detailed information on DLPI, refer to the "DLPI Overview".|
|TCP/IP||Provides a highly robust and transparent interface. In most cases, it is transparent to the application that the underlying virtual circuit was reset or cleared. As long as the application remains active, the X.25 IF driver attempts to re-establish the virtual circuit. If it succeeds in establishing the connection, the power-off/power-on cycle is transparent to the application. For information on sockets, refer to "Sockets Overview" in AIX Version 4.3 Communications Programming Concepts. For information on TCP/IP commands, refer to AIX Version 4.3 Commands Reference.|
|NPI||Receives N_DISCON_INDs on all active SVCs. Likewise, N_RESET_INDs (RESET_reason: N_NET_LINK_DOWN/N_NET_LINK_UP) are received on all configured and bound PVCs. The application needs to properly handle these primitives. Note that all N_BIND_REQs are maintained as long as the application does not unbind, close, or exit. This implies that all PVCs remain bound, and all listens are still active. All SVCs need to be re-established through new N_CONN_REQs/N_CONN_INDs. For detailed information on NPI, refer to the "NPI Overview".|
|COMIO Emulation||In the case of a base X.25 API application running through the COMIO emulator, all active calls (SVCs) are cleared and all PVCs are reset. Before the sessions are re-established, the application needs to ensure that it has properly handled the completion of the aborted sessions. A Library API user needs to read all clears and resets (x25_receive), while an application using the COMIO emulator need to complete a CIO_HALT/ CIO_HALT_DONE cycle for all sessions. It is not necessary for the application to reinitialize (x25_init), reattach any PVCs (x25_pvc_alloc/ CIO_START-logical_channel), or re-establish any listens (x25_listen/ CIO_START-listen_name). However, it is up to the application to re-establish any SVCs (x25_call/CIO_START, x25_call_accept/ CIO_START). For detailed information on the base X.25 API, refer to "X.25 Application Programming Interface" in "Common Input/Output Emulation".|
|PAD||All active PAD connections are cleared. If using the xspad application, a CLEAR is received on all active sessions. PAD sessions can be re-established by issuing the appropriate CALL commands. For more detailed PAD information, refer to "Packet Assembler/Disassembler (PAD) Overview".|
The following is a list of Power Management warnings:
|Changing configuration during suspend/hibernation|
|Altering the system configuration, such as devices, ports, etc., while the system is in the suspend or hibernation state transitions can cause unpredictable results. This could cause loss of data, file system corruption, system crashes, or a failure to resume from the suspend or hibernation states.|
|Non-PM-aware device drivers|| If a device driver is installed that is not PM-aware, unpredictable results could occur when resuming from suspend or hibernation. If a non-PM-aware device driver is installed, the suspend and hibernation states must NEVER be used. The following command can be run with root authority to disable the states, effective on the next system boot:
To re-enable these states, use the following command, effective on the next system boot:
|Booting from CD-ROM or other media after hibernation|
|Accessing the rootvg from maintenance mode, such as a CD-ROM boot when a valid hibernation image exists, can result in loss of data and file system corruption.|
|Maintenance modes after hibernation||To avoid loss of data and file system corruption, maintenance modes should only be used after normal system shutdown or power-off, not after a hibernation power-off.|
|Network connections during suspend/hibernation|
| Network connections are disconnected during the suspend and hibernation states. Since locally cached data will not be available to other nodes on the network during this time and network activity cannot be monitored by the local node during this time, it is recommended that the suspend and hibernation states NOT be used when running network interfaces such as X.25, TCP/IP, NFS, AFS, DCE, SNA, OSI, NetBIOS, etc.
The following command can be run with root authority to disable the states, effective on the next system boot:
To re-enable this function, use the following command, effective on the next system boot:
|Power Button Behavior|| When PM is enabled, the power button is software controlled. If there is a system problem, the software necessary to make the requested Power Management state transition using the power switch may not be able to run. In such a situation, it should always be possible to turn off the power immediately by pressing the power button three times quickly (within a two-second period). This overrides whatever state transition was selected for the power switch and requires a full boot.
In addition, if the PM daemon (/usr/bin/pmd) is never started (by default, an entry in /etc/inittab), the power switch acts as if there was no Power Management. A single button press turns off the system. If /usr/bin/pmd is started and then killed, the first two button presses are ignored and the third turns off the system. These button presses can be over any period of time as long as /usr/bin/pmd is not restarted.