Chapter 92 SMN (External ServerNet SAN Subsystem) Messages

Cause   The External ServerNet SAN manager process has started.

Effect  The External ServerNet SAN Manager process is running.

Recovery  This is an informational message. No corrective action is required.

Cause  The External ServerNet SAN manager process terminated voluntarily. Either it was terminated by an operator command, or an environmental problem caused it to self-terminate. If this event is due to self-termination, an associated SMN 4010 (SANMAN-Additional-Information) message reports the environmental problem found by the External ServerNet SAN manager process.

Effect  The External ServerNet SAN manager process is no longer running.

Recovery  If this event is due to self-termination, follow recovery instructions for the SMN 4010 event. After correcting any environmental problems, restart the External ServerNet SAN manager process with an operator command.

Cause  Either the External ServerNet SAN manager process was initialized for the first time, or a backup process has become the primary process.

Effect  The External ServerNet SAN manager process is running in the indicated processor.

Recovery  This is an informational message. No corrective action is required.

Cause  The External ServerNet SAN manager process has successfully created a backup process.

Effect  The External ServerNet SAN manager process is no longer vulnerable to a single failure.

Recovery  This is an informational message. No corrective action is required.

Cause  An attempt to create an External ServerNet SAN manager backup process has failed. For information on process-creation errors and error detail subcodes, see the Guardian Procedure Errors and Messages Manual.

Effect  Until a backup process is started, External ServerNet SAN management is vulnerable to a single failure. The External ServerNet SAN manager process attempts to start a backup process immediately if any processor in its processor list other than that used by the primary process is running. The External ServerNet SAN manager process makes two restart attempts in each processor eligible to contain the backup process. Each failed attempt results in an SMN 4005 message. If all restart attempts fail, an SMN 4007 message is generated.

Recovery  This is an informational message. Although no corrective action is required, the message might provide information for recovery in the event of an SMN 4007 message.

Cause  The backup process of the External ServerNet SAN manager process pair failed.

Effect  Until a backup process is started, External ServerNet SAN management is vulnerable to a single failure. The External ServerNet SAN manager process attempts to start a new backup process immediately if any processor in its processor list other than that used by the primary process is running. The External ServerNet SAN manager process makes two restart attempts in each processor eligible to contain the backup process. Each failed attempt results in an SMN 4005 message. If all restart attempts fail, an SMN 4007 message is generated.

Recovery  This is an informational message. Although no corrective action is required, the message might provide information for recovery in the event of an SMN 4007 message.

Cause  Either there is no processor available for running the backup process, or there have been multiple failures of the backup process or attempts to create a backup process. If this event is due to backup process-creation failures, there is associated SMN 4005 messages. Other possible precursors are SMN 4006 and SMN 4008 messages.

Effect  The External ServerNet SAN manager process runs without a backup, and the External ServerNet SAN subsystem is vulnerable to a single failure. Whenever a processor in its processor list is reloaded, the External ServerNet SAN manager process attempts to create a backup there.

If this event is caused by repeated backup failures or backup process-creation failures, the External ServerNet SAN manager process periodically attempts to create a backup.

Recovery  Either reload the processors on the processor list for the External ServerNet SAN manager process, or use the information in the associated SMN 4005, 4006, or 4008 messages to determine the cause and recovery actions for backup process-creation failures. To list the processors that have been configured in the processor list for the External ServerNet SAN manager process, issue an SCF INFO command.

Cause  The backup process failed, or it was terminated by the primary (for example, if the primary found a fatal error when checkpointing to the backup).

Effect  Until a backup process is started, External ServerNet SAN management is vulnerable to a single failure. The External ServerNet SAN manager process attempts to start a new backup process immediately if any processor in its processor list other than that used by the primary process is running. The External ServerNet SAN manager process makes two restart attempts in each processor eligible to contain the backup process. Each failed attempt results in an SMN 4005 message. If all restart attempts fail, an SMN 4007 message is generated.

Recovery  This is an informational message. Although no corrective action is required, the message might provide information for recovery in the event of an SMN 4007 message.

Cause  An internal trace was initiated on the External ServerNet SAN manager process.

Effect  Trace data has been dumped into the EMS log. The External ServerNet SAN manager state is unchanged.

Recovery  This is an informational message. No corrective action is required.

Cause  The External ServerNet SAN manager process found an environmental problem. Possibly the processor list in the startup message is invalid, the process name is wrong (not $ZZSMN), the process was not started under the SUPER.SUPER user ID, an internal coding error occurred, or the process was inadvertently started in a system type that does not require or support the External ServerNet SAN manager process. This message is usually followed by a termination message.

Effect  This is an informational message, but normally the External ServerNet SAN manager process will terminate after detecting an environmental problem.

Recovery  Corrective action might be required to correct the environmental problem:

Cause  SANMAN made a comparison of its own version and that of the NonStop Kernel IBC and SMC drivers that it is using. One or both of the versions was determined to be incompatible.

Effect  The External ServerNet SAN Manager process terminates.

Recovery  Check SPR requisites for NonStop Kernel (T9050) and SANMAN (T0502). The operator needs to ensure that the versions of SANMAN and the NonStop Kernel IBC and SMC drivers are compatible.

Cause  The External ServerNet SAN manager process encountered an error using the DSM trace routines.

Effect  Any pending trace is terminated.

Recovery  Investigate the cause of the error. Reissue the SCF TRACE command. If the problem persists, contact your service provider.

Cause  This message is generated by the External ServerNet SAN manager when there is an attempt to discover an external fabric, but the discovery fails. Discovery of an external fabric may fail due to the following causes:

SANMAN tries to discover an external fabric in the following cases:

Effect  The external ServerNet fabric discovery fails. The External ServerNet SAN manager process will not attempt to bring up the physical ServerNet connection between the node and the external fabric. The node will not be able to communicate with other remote nodes via that fabric. SANMAN will continue to perform periodic attempts to discover the fabric, but in most cases these will succeed only after the condition that caused the external fabric discovery failure is corrected.

Recovery  Recovery is dependent on the cause:

Cause  External ServerNet fabric discovery was successful.

Effect  SANMAN proceeds and tries to bring up the physical ServerNet connection between the node and the external fabric by programming the NNA (Node Numbering Agent) for that connection.

Recovery  This is an informational message. No corrective action is required.

Cause  The External ServerNet SAN manager process failed to activate the physical ServerNet connection to an external fabric:

Effect  The physical ServerNet connection between the node and the external fabric is down. The node is not able to communicate with other remote nodes via that fabric.

Recovery  Recovery depends on the cause:

Cause  The physical connection between the node and an external ServerNet fabric was brought up successfully after the External ServerNet SAN manager process programmed the Node Numbering Agent (NNA) with the node number assigned by that fabric.

Effect  Physical access to the external ServerNet fabric indicated in the event is now enabled for the node.

Recovery  This is an informational message. No corrective action is required.

Cause  A previously active connection to an external ServerNet fabric was downed.

Effect  The physical ServerNet connection between the node and the external fabric is down. The node cannot communicate with other remote nodes via that fabric.

In the case of a power failure, if both external fabric connections were active before the power outage, the External ServerNet SAN manager process generates one event for the X fabric and one event for the Y fabric.

Recovery  Recovery depends on the cause.

Cause  The External ServerNet SAN manager process was not able to register with NonStop Kernel Configuration Services.

Effect  The External ServerNet SAN manager process relies on NonStop Kernel Configuration Services for fast notification of certain configuration and status changes, such as Cluster Connectivity CRU insertion and removal events, and link-alive status changes in the connection to an external fabric. If the External ServerNet SAN manager fails to register with NonStop Kernel Configuration Services, it can still detect configuration and status changes by means of periodic checks although a delay might occur in detecting configuration and status changes. It might take longer for the External ServerNet SAN manager to bring up the connection to an external fabric after a repair.

Recovery  Stopping one or more subsystems that register with NonStop Kernel Configuration Services should allow the External ServerNet SAN manager to register itself. Registration occurs when the External ServerNet SAN manager is initialized. The recommended long-term solution is to request a NonStop Kernel Configuration Services (T6586) SPR capable of supporting a larger number of registered subsystems.

If the external ServerNet SAN manager appears to be slow in detecting configuration changes, and you want to accelerate recovery of the external fabric connection after a repair, use the following workaround. Issue the SCF PRIMARY PROCESS $ZZSMN command to force the primary and backup external ServerNet SAN manager processes to switch roles. Upon takeover, the new primary immediately checks the external ServerNet SAN subsystem for configuration and status changes.

This list includes all possible errors returned by the NonStop Kernel Configuration Services CONFIG_SPEV_EVENTTYPE_REGISTER_ routine:

Cause  The External ServerNet SAN manager attempted to configure the ServerNet node number by writing to the internal registers of a Node Numbering Agent (NNA). After the write operation completed, the External ServerNet SAN manager read the register contents back for verification purposes, compared the contents of the NNA registers with the intended values, and found that at least one of the register values did not match the intended value.

Effect  The External ServerNet SAN manager automatically retries to program the NNA and possibly resets the NNA during the retry. Until the NNA is programmed correctly, the physical ServerNet connection to the external fabric indicated by the event remains down. If the retries to program the NNA fail, an SMN 4103 message is generated.

Recovery  This is an informational message. Although no corrective action is required, information for recovery might be available in the SMN 4103 message.

Cause  The External ServerNet SAN manager detected that the ServerNet node number assigned by the external fabrics to the node has changed, because the node was moved to a different position in the ServerNet Cluster topology. The ServerNet node number that the External ServerNet SAN manager had previously configured in the Node Numbering Agents (NNAs) is no longer valid.

Effect  The External ServerNet SAN manager configures the new ServerNet node number in the Node Numbering Agents (NNAs).

Recovery  This is an informational message. No corrective action is required.

Cause  The External ServerNet SAN manager made a call to an SP I/O library routine, but it failed.

Effect  The External ServerNet SAN manager automatically retries the SP I/O library routine, possibly after destroying its previous session with the Service Processor and starting a new session. If the retries fail, and the SP I/O library routine had been called by the External ServerNet SAN manager to program an NNA, an SMN 4103 event occurs.

Recovery  The External ServerNet SAN manager automatically retries the SP I/O library routine. If the errors persist (as indicated by additional SMN 4204 messages), an SMN 4103 message is generated. The Service Processor might have to be initialized, or the Service Processor firmware might have to be upgraded. Contact your service provider for assistance.

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  SANMAN has detected at least one external port status change in a ServerNet switch.

Effect  The status of switch port or ports (including neighbors) indicated has been changed.

Recovery  Depends on the kind of switch. When the switch is a 6770 switch:

Recovery   When the switch is a 6780 switch:

When the new status is:

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  The operator issued an ALTER SWITCH command, or if the physical hardware is a 6770 switch SANMAN detected that the required fabric setting attribute of a 6770 switch was set to None when discovering an external ServerNet fabric. In the latter case, SANMAN will automatically sets the switch fabric setting attribute to match the identity of the external fabric in which the switch was discovered.

Effect  SANMAN has successfully altered an attribute of a ServerNet switch configuration.

Recovery  This is an informational message. No corrective action is required.

Cause  The primary SANMAN process attempted to register with a NonStop Kernel Driver, but registration failed.

Effect  If the failed attempt was to the IBC Driver, the primary SANMAN process will not be able to communicate with the external ServerNet fabrics via IBC packets, and will terminate itself. The backup SANMAN will attempt to register with the NonStop Kernel IBC Driver in a different processor when it becomes the new primary. The SANMAN process pair will terminate if registration with the NonStop Kernel IBC Driver does not succeed in at least one processor in SANMAN's configured CPU list. If the failed attempt was to the SMC Driver, the primary SANMAN process will not be able to communicate directly with 6780 switches via ServerNet RDMA reads and writes, and will terminate itself. The backup SANMAN process will take over and attempt to register with the SMC Driver when it becomes the new primary. The SANMAN process pair will terminate if registration with the NonStop Kernel SMC Driver does not succeed in at least one processor in SANMAN's configured CPU list.

Recovery  SANMAN will automatically attempt to register with the NonStop Kernel Driver on a different processor. A ZZSA* save abend file will be created when the primary SANMAN process terminates. The ZZSA* save abend file should be provided for analysis, along with the ZZSV* service log event file containing the SMN 4207 event. If the error detected by SANMAN was a failure to register a permissive listener interrupt handler, the recommended long-term solution is to request a TNet Millicode (T8460) product revision capable of supporting a larger number of registered subsystems. If the errors indicate that SANMAN has attempted to register with the indicated driver more than once, the errors are programming errors. SANMAN should not attempt to register with a NonStop Kernel Driver more than once. Ensure that the saveabend file and event logs are preserved and report this incident to your HP service provider. If the error code implies that there is a mismatch between the executing versions of SANMAN and the NonStop Kernel, the event logs should contain an SMN 4011 event with additional details on the version mismatch between SANMAN and the NonStop Kernel. The operator needs to ensure that the versions of SANMAN and the NonStop Kernel IBC and SMC drivers are compatible. Check the level of the installed product revisions for both T9050 and T0502 and the product revision requisites for these two products. If the two do not match, install any maintenance required to ensure that the products are at compatible levels. If the error codes indicate a shortage of memory in NonStop Kernel data space, it is highly likely that the automatic retry when the backup takes over will recover this situation. If it does not, the operator may attempt to stop other processes to free up system global memory then retry starting the SANMAN process using the SCF command START PROCESS $ZZKRN.ZZSMN. Otherwise, determine and correct the cause of the error. When the error is corrected, it may be necessary to manually restart SANMAN by using the SCF START PROCESS $ZZKRN.ZZSMN command.

	NOTE: This event applies only to the 6770 switch.

Cause  The ServerNet SAN manager has detected at least one power environment status change in a ServerNet switch.

Effect  Some element or elements of the AC power in a ServerNet switch has changed in status. These changes could include the detection of an error or the detection of recovery from a previously detected error.

Recovery  The following status changes are informational only and require no corrective action:

Other status changes require recovery action, depending on the change reported.

	NOTE: This event applies only to the 6770 switch.

Cause  SANMAN has detected at least one firmware and/or hardware status change in a ServerNet switch.

Effect  Depends on the status change. An error has been detected or a repair has been detected in one or more aspects of the ServerNet Switch firmware or hardware.

Recovery  The following status changes are informational only and require no corrective action:

No unknown errors.
Program checksum is now OK.
Current persistent router configuration was loaded.
New configuration OK after configuration download.
At least one configuration OK after configuration download.
SRAM Memory test OK.
FLASH sector test OK.
SEEPROM Checksum OK.
No SBUSY errors detected.
No FLASH Program errors detected.
Both power supply fans are now OK.
Switch is now responding.
SP is no longer over allocated space.
Program CRC is now OK.
Switch configuration CRC is now OK.
Firmware images are identical.
Configuration images are identical.
No router self check.
Flash ID string is now OK.
No flash boot lockout 0 errors detected.
No flash boot lockout 1 errors detected.

Other status changes require recovery action, depending on the change reported.

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  The operator issued a LOAD SWITCH command to download a firmware, configuration, or FPGA file into a ServerNet switch.

Effect  SANMAN has successfully loaded the download file into the ServerNet switch.

Recovery  This is an informational message. No corrective action is required.

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  SANMAN has detected that the indicated ServerNet switch has been reset.

Effect  The specified ServerNet switch has been reset.

Recovery  If the reset type is Watchdog Level 2 Timer Expiration or Watchdog Level 3 Timer Expiration, contact your service provider. Also, check for the presence of OSM alarms and perform any recommended recovery actions. Otherwise, this is an informational message. No corrective action is required.

	NOTE: This event applies only to the 6770 switch.

Cause  SANMAN has detected at least one port status change in a neighbor ServerNet switch.

Effect  The status of the neighbor switch port or ports indicated have been changed.

Recovery  The following messages require corrective action: Cabling may be incorrect. Check cables Check if a valid switch configuration block is loaded on the neighbor switch connected to that port. Check cabling. If cabling appears to be correct, make sure the correct configuration image is loaded on the neighbor switch connected to that port.

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  SANMAN has detected an error with respect to the neighbor ServerNet switch.

Effect  The switch port will not be enabled for ServerNet pass-though traffic.

Recovery  The majority of the neighbor check errors require corrective actions, check for the presence of OSM alarms and perform any recommended recovery actions.

	NOTE: This event applies to the 6770 switch and the 6780 switch.

Cause  The ServerNet switch detected a backpressure incident and became blocked for ServerNet traffic. This event appears only if T0502AAG and T0569AAE (or superseding product revisions) are installed. T0502AAG and T0569AAE are included in the G06.14 product version.

Effect  The ServerNet switch firmware automatically recovered the switch from the backpressure incident by performing a selective reset of the switch. If the cluster switch is running T0569AAE firmware (or a superseding product revision), detection and recovery from a blocked switch incident is typically performed in a few milliseconds. In most cases, selective reset recovery from a blocked switch incident does not cause any loss of interprocessor communication (IPC) connectivity through the cluster switch under recovery. For more information about blocked switch incidents, see Support Note S01122.

Recovery  Use the SCF STATUS SUBNET $ZZSCL, PROBLEMS command to validate the connectivity status in the cluster and confirm that all of the remote IPC paths were automatically repaired. If paths are found to be down, verify the status of the backpressured switch and of all NNAs in the cluster by using OSM or SCF. Use the diagnostic commands and recovery steps documented for an unprogrammed NNA in Support Note S01122.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has detected a change in the status of an internal port on one of the internal routers in a switch.

Effect  The status of the indicated router port, internal to the switch, has been changed.

Recovery  Reset, Uninstalled, and Link Alive, enabled are informational messages. No corrective action is required for these status changes. Recovery from Link Dead or Link Alive, disabled depends on the problem that caused the change to this status.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has detected a change in the status of at least one component of the power system in a switch.

Effect  The status of the indicated component of the power system has been changed.

Recovery  If the new status, as displayed in the event, indicates that the component has failed, see the OSM alarm and follow the suggested repair action. Otherwise, this is an informational message and no recovery action is required.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has detected a change in the status of a component of the firmware or hardware in a switch.

Effect  The status of the indicated component of the switch has changed.

Recovery  If the new status, as displayed in the event, indicates that the component has failed, see the OSM alarm and follow the suggested repair action. Otherwise, this is an informational message and no recovery action is required.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has detected the occurrence of an internal error in one of the ASICs in a switch.

Effect  If the error is from a Router 2, connectivity to the External ServerNet fabric via the effected ASIC is lost until the ASIC is reset. If the error is from a Colorado 2xy, management command capability is lost until the ASIC is reset. However, in both cases, the ASIC is automatically reset by the switch firmware.

Recovery  Once the ASIC reset is complete, any lost connections are automatically recovered. OSM tracks the occurrence of this event, and beyond a threshold level, will raise an alarm. If the OSM alarm appears, follow the suggested repair action. If no OSM alarm appears, this is an informational message and no recovery action is required.

	NOTE: This event is emitted for 6780 switches and beyond, only. There is going to be one event for each router port with errors.This event is not emitted during SANMAN initialization or takeover processing.This event applies only to the 6780 switch.

Cause  SANMAN has detected the occurrence of a specific port error in one of the router ASICs in a switch.

Effect  Depends on the error.

Recovery  See if OSM is reporting an alarm for the port, and follow the repair actions for the alarm.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN invoked an SMC Driver API interface function. The function returned a code other than SMC_RTN_OK.

Effect  SANMAN will automatically retry the SMC Driver API call. If subsequent retries fail, and if this attempt to invoke the SMC Driver is the result of a request from a SANMAN client, the client request will ultimately receive a failure response.

Recovery  This event is primarily provided for support personnel. SANMAN will automatically retry the SMC Driver API call. If the error persists (as indicated by additional SMN 4220 events), use the error and error detail codes in the event to determine and correct the cause of the failure. Then retry the high level command that failed.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has detected a change in the status of a CRU in a switch.

Effect  The status of the indicated component of the 6780 switch has changed.

Recovery  If the new status, as displayed in the event, indicates that the component has failed, see the OSM alarm and follow the suggested repair action. Otherwise, this is an informational mesage and no recovery action is required.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has received an indication that an update has reached a new phase.

Effect  The status of the indicated component of the switch has changed.

Recovery  No recovery needed.

	NOTE: This event applies only to the 6780 switch.

Cause  SANMAN has received an indication that an update has reached a new phase.

Effect  Not all router port error counters are going to generate an event SMN 4219 during the supression interval of time.

Recovery  No recovery needed. An event SMN 4219 with the summary of the router port error counters that have changed values during the suppression interval is generated after the interval is over.

Cause  The External ServerNet SAN manager process (SANMAN) encountered an error while using the HP NonStop operating system configuration services application programming interface (API) for access to the External ServerNet SAN subsystem configuration record.

Effect   If this error occurs during process startup, SANMAN infers zone-to-zone distances in a long-distance ServerNet cluster topology from the configuration tags loaded on switches, as opposed to using the zone-to-zone distance attributes stored in its private configuration record. If this error occurs later, the action is prompted by an SCF [ALTER | START | STOP] SUBSYS $ZZSMN command. In this case, the command fails with an error.

Recovery   Restart the process or reissue the failed SCF command. If the error persists, contact your service provider.

	NOTE: This event applies only to the 6780 switch.

Cause  Firmware reads the internal temperature of the logic board in the Servernet switch. If there is an error in reading, SANMAN detects it and displays this event.

Effect   The internal temperature of the logic board in the ServerNet switch is not displayed correctly.

Recovery   This is an informational message, and no recovery action is required.

	NOTE: This event applies only to the 6780 switch.

Cause  Firmware can now read the internal temperature of the logic board in the ServerNet switch correctly. SANMAN detects this and displays this event.

Effect   The internal temperature of the logic board is now displayed correctly.

Recovery   This is an informational message, and no recovery action is required.