Troubleshooting the SLSA Subsystem This page is a jumping off point for troubleshooting information for the ServerNet LAN Systems Access (SLSA) subsystem. The following flowchart guides you through the SLSA troubleshooting process. Click on any box in the flowchart to obtain detailed information about a troubleshooting topic. Tip: You should always begin at Step 1 in the flowchart. The order in which you perform the remaining steps should be determined by the data you gather in Step 1.
What to Do if You Can't Solve a Problem If you are unable to solve a SLSA subsystem problem, collect the appropriate information and submit it to the Global Customer Support Center (GCSC) for analysis.
Finding SLSA Subsystem Event Messages in the Event Log When you view events using the OSM or TSM Event Viewer, the subsystem name (or, in rare cases, the subsystem number) is shown in the SSID column. The subsystem name for events generated by the ServerNet LAN Systems Access (SLSA) subsystem is SLSA and the subsystem number is 193.
Loss of media For a TRSA port: 4013, transient fault number 3023 (the Token-Ring cable was pulled out, the MAU had a fault, the Token-Ring cable had a fault, or the transceiver had a problem) For a non-TRSA port: 4013 (the status of the link pulse changed) Cause, effect, and recovery information for all event messages generated by the SLSA subsystem is provided in the Operator Messages Manual.
Viewing SLSA Adapter Alarms Use this procedure to view an alarm generated by any of the following: ● ATM ServerNet Adapter (ATM3SA) ● Common Communication ServerNet adapter (CCSA) ● Ethernet 4 ServerNet adapter (E4SA) ● Fast Ethernet ServerNet adapter (FESA) ● Gigabit Ethernet ServerNet adapter (GESA) ● Multifunction I/O Board/Ethernet (MFIOB/E) adapter ● Token-Ring ServerNet adapter (TRSA) Note: The following instructions are applicable to the OSM package and to TSM client software Version 7.0 and later.
Recovering From a SLSA Adapter Alarm Note: The following instructions are applicable to the OSM package or to TSM client 5.0 or later and TSM server version T7945AAE (G06.02 RVU) or later. This page explains how to recover from a ServerNet LAN Systems Access (SLSA) subsystem alarm displayed by the OSM Service Connection or TSM Service Application.
Ethernet 4 ServerNet Adapters (E4SAs), Fast Ethernet ServerNet Adapters (FESAs), and Gigabit Ethernet ServerNet Adapters (GESAs): Cause: The download operation code or firmware version does not match the NonStop Kernel operating system version. Recovery: If the firmware on the adapter (specified by the FIRMWAREFILENAME attribute) is not current, update it by following the instructions in Updating the Firmware on a SLSA Adapter.
● GESA: Gigabit Ethernet Adapter Installation and Support Guide For Token-Ring ServerNet Adapters (TRSAs): Cause: The Token-Ring cable is faulty, is not connected to an operational hub, or is not connected to the adapter. Recovery: Make sure the cable is operational and is connected to the adapter. Replace or reconnect the cable, as required. Make sure the hub is operational and replace it, as required. Cause: The LAN speed does not match the ring speed of the physical interface (PIF).
For Multifunction I/O Board/Ethernet Adapters (MFIOB/Es): Cause: The ServerNet bus interface (SBI) application-specific integrated circuit (ASIC) has detected a ServerNet port error. Recovery: Make sure that the SP is operational. See Service Processor (SP) Troubleshooting Tips for more information. Cause: The service processor (SP) is repeatedly resetting itself. Recovery: Make sure that the SP is operational. See Service Processor (SP) Troubleshooting Tips for more information.
Wrong PIC Type Alarm This alarm is generated for a ServerNet addressable controller (SAC) on a CCSA when the plug-in card (PIC) type obtained from the LAN manager process ($ZZLAN) is invalid. The supported PIC types are SS7TE, SS7TE2, and SS7TE3. To recover from this alarm, you must replace the PIC. For information about replacing a PIC, see Replacing or Installing ServerNet Adapter Plug-In Cards (PICs).
Updating the Firmware on a SLSA Adapter The firmware for Ethernet 4 ServerNet adapters (E4SAs), Token-Ring ServerNet adapters (TRSAs), Fast Ethernet ServerNet adapters (FESAs), Common Communication ServerNet adapters (CCSAs), Gigabit Ethernet ServerNet adapters (GESAs), ATM ServerNet adapters (ATM3SAs), and MIOE adapters (on MFIOBs) is contained in 510 disk files that reside in the $SYSTEM.SYSnn subvolume on the NonStop S-series server.
2 Alter the firmware file for each SAC. Use the SCF ALTER SAC command: ALTER SAC $ZZLAN.., FIRMWAREFILENAME $SYSTEM.SYS.
Preparing a SAC for the Test Verify Test Action or Firmware Update The Test Verify test and firmware update actions in OSM or TSM require that you stop the ServerNet addressable controller (SAC) and any active communications lines using the SAC. This page explains how to prepare a SAC before executing the Test Verify test action or Firmware Update and how to resume SAC operation after the test action or Firmware Update has been performed.
Resuming Operation on a SAC Perform the following steps to resume operation on a SAC: 1 Restart the SAC. Use the SCF START SAC command with the SUB ALL option: START SAC $ZZLAN.., SUB ALL 2 Restart any stopped communications lines. For example: -> START LINE $LINE1 3 Resume customer applications.
Quiescing Customer Applications 1 Notify end users that applications will be temporarily unavailable. 2 Perform any actions necessary to quiesce customer applications. Note: The actions required to perform this step depend on the customer's application.
Resuming Customer Applications 1 Perform any actions necessary to resume customer applications. Note: The actions required to perform this step depend on the customer's application. 2 Notify end users that applications are now available.
Example: Displaying Detailed Information for a PIF This is an example of the SCF INFO PIF command with the DETAIL option: -> INFO PIF $ZZLAN.E0153.1.A, DETAIL SLSA Detailed Info PIF \FUDD.$ZZLAN.E0153.1.A Hardware MAC Address.... 08:00:8E:00:8E:60 Interface Speed......... N/A Max Frame Size.......... 17832 Min Frame Size.......... 32 *NodeMACAddress.......... 08:00:8E:00:8E:60 PIF Type................ Token Ring TRSA Specific Info *ActivityMonitor....... *EarlyTokenRelease..... *MaxSessions...........
Gathering PIF Statistics The ServerNet LAN Systems Access (SLSA) subsystem enables you to gather statistical information for a physical interface (PIF) on an Ethernet 4 ServerNet adapter (E4SA), Fast Ethernet ServerNet adapter (FESA), or Token-Ring ServerNet adapter (TRSA). PIF statistics can be used to help you diagnose ServerNet LAN Systems Access (SLSA) subsystem problems.
Example: Gathering PIF Statistics The following is an example of the SCF STATS PIF command: -> STATS PIF $ZZLAN.E0153.1.A SLSA Stats PIF \FUDD.$ZZLAN.E0153.1.A Sample Time..... 03 Nov 1998, 12:49:38.309 Reset Time...... 03 Nov 1998, 11:26:26.327 Octets Transmitted OK........... 31444 Octets Received OK.............. 25720 General Send Stats Unicast Frames Transmitted.. Non-Unicast Frames Transmit. Frames Discarded............ Errors...................... Current OutQueue Length ....
Time Stats Sample Time is the time when the statistics were taken. Reset Time is the time when statistics counters were last reset. PIF statistics are reset when a connection is established between the host and the adapter (that is, when the PIF changes from the STARTING to the STARTED state). PIF statistics are also reset whenever ownership of the SAC changes. Octet Stats Octets Transmitted OK is the number of bytes transmitted to the LAN. Octets Received OK is the number of bytes received from the LAN.
802.3 Send Stats Transmit Underruns is the number of frames that had their transmission aborted because memory could not be accessed quickly enough to allow transmission. Defer Packets is the number of frames that could not be transmitted immediately because the LAN was in use. Send Late Collision is the number of frames that had their transmission aborted because a collision occurred before the completion of the retry process.
Burst Errors indicates that the adapter repeated or copied a frame or token and a violation of the hardware clocking protocol was detected. A high count in this field might indicate a hardware problem in the upstream neighborhood of this adapter. AC Errors indicates that the upstream neighbor of this adapter could not set the ARI/FCI bits in a Monitor Present frame. A high count in this field might indicate a hardware problem in the upstream neighborhood of this adapter.
Lobe Wires is incremented when the adapter detects an open or short circuit between the adapter and the multistation access unit (MAU). A non-zero count indicates an error condition. Removes is incremented when the adapter has received a remove-ring-station MAC frame. An incrementing count in this field indicates a hardware fault in the adapter. Singles is incremented each time the adapter recognizes that it is the only adapter on the ring. This field is provided for informational purposes only.
Tracing SLSA Subsystem Processes and Objects You can trace the activity of the following ServerNet LAN Systems Access (SLSA) subsystem processes and objects: ● LAN manager process ($ZZLAN) ● LAN monitor processes ● Physical interfaces (PIFs) ● ServerNet addressable controllers (SACs) Tracing enables you to see the history of a SLSA subsystem process or object, including significant points in the internal processing of the traced entity.
TRACE [ / OUT / ] { MON | PIF | PROCESS | SAC } { [ [ [ [ [ [ [ [ [ , , , , , , , , , , STOP BULKIO | NOBULKIO COUNT LOCKSIZE NOCOLL PAGES RECSIZE SELECT TO WRAP } ] ] ] ] ] ] ] ] ] ... } Note: If TO is specified, a new trace is initiated unless is invalid, the file cannot be opened, or a trace is already active for the object.
an integer in the range 4 through 1024 or is equal to 0. If PAGES is omitted or if is equal to 0, the default value of 64 pages is used. is the length of the data in the trace-data records. You can specify as 0 or as an integer in the range 16 through 4050. The length of the trace header, which is 8 bytes, is not included in . If RECSIZE is omitted or if is equal to 0, a default value of 120 bytes is used.
INTMSG 5 DIH 6 MEMORY 7 Trace internally generated messages Trace calls to the driver/interrupt handler routines Trace management of resources for internal memory for the LAN monitor process for PIF Object Keyword Number Meaning ALL -1 Trace all items CALLIN 8 CALLOUT 9 CALLLOCAL 10 Trace local call for PIF object in DIH PING 11 Trace PIF object PING related action in DIH SMACH 12 Trace PIF state machine operations for SAC object SNET 13 Trace PIF object ServerNet
CALLOUT 9 Trace call out to external components for SAC object in DIH CALLLOCAL 10 Trace local call for SAC object in DIH PING 11 SMACH 12 SNET 13 Trace SAC object ServerNet events SNETINT 14 Trace SAC object ServerNet interrupt events QSERV 15 Trace SAC object queue service TXDATA 16 Trace SAC object outbound data RXDATA 17 Trace SAC object inbound data LMOMSG 18 Trace messages between the LAN monitor process and DIH for SAC objects ERROR 19 Trace DIH errors for SAC object Tr
Verifying the SLSA Subsystem Processes and Objects This procedure describes how to verify that the required ServerNet LAN Systems Access (SLSA) subsystem processes and objects are started for a ServerNet adapter. If you find that a SLSA subsystem process or object is not in the STARTED state, see Starting the SLSA Subsystem Processes and Objects. Note: Angle brackets (for example, ) are used in command syntax to indicate values that you must provide.
4 Verify that the ServerNet addressable controllers (SACs) are in the STARTED state. Use the SCF STATUS SAC command: STATUS SAC $ZZLAN..* The example shows the output of the SCF STATUS SAC command. You can use the DETAIL option with the SCF STATUS SAC command to obtain additional information. The example shows the output of the SCF STATUS SAC command with the DETAIL option and explains how to interpret it.
INFO SAC command with the DETAIL option. For example: INFO SAC $ZZLAN.., DETAIL ● If there is a dump file in the current SYSnn, check its creation date. Provide the dump file to the GCSC if the cause of the failure is unknown. Also provide any related event messages for the SLSA subsystem and the VPROC of the dump file.
data access to the LIF will be down. For more information about PIF problems, see Step 5.
Starting the SLSA Subsystem Processes and Objects This procedure describes how to start the required ServerNet LAN Systems Access (SLSA) processes and objects. Use the SCF STATUS command as described in Verifying the SLSA Subsystem Processes and Objects to verify that a process or object has entered the STARTED state. Note: Angle brackets (for example, ) are used in command syntax to indicate values that you must provide.
5 To start a physical interface (PIF), use the SCF START PIF command: START PIF $ZZLAN... Note: The SCF START PIF command returns no error if the PIF goes into the STARTING state. See Verifying the SLSA Subsystem Processes and Objects for reasons why a PIF might remain in the STARTING state. 6 To start a logical interface (LIF), use the SCF START LIF command: START LIF $ZZLAN.
Example: Verifying That the LAN Manager Process Is Started This is an example of the SCF STATUS PROCESS command: -> STATUS PROCESS $ZZKRN.#ZZLAN NONSTOP KERNEL - Status PROCESS \COWBOY.$ZZKRN.#ZZLAN Symbolic Name Name State ZZLAN $ZZLAN STARTED Sub Primary PID 0 ,21 Backup PID 1 ,16 Note that the LAN manager process is in the STARTED state.
Example: Displaying Detailed Status for the LAN Manager Process This is an example of the SCF STATUS PROCESS command with the DETAIL option: -> STATUS PROCESS $ZZLAN, DETAIL SLSA Detailed Status PROCESS \FUDD.$ZZLAN Heap Memory Limit........ Heap Memory Used......... PID Backup............... PID Primary.............. Priority................. QIO Pool Current......... QIO Pool Limit........... State.................... Trace Filename........... Trace Status.............
Example: Verifying That the LAN Monitor Processes Are Started This is an example of the SCF STATUS MON command: 1-> ALLOW ALL ERRORS 2-> STATUS MON $ZZLAN.#ZLM* SLSA Status MON Name $ZZLAN.#ZLM01 $ZZLAN.#ZLM00 State STARTED STARTED PID Priority ( 1,289) 180 ( 0,283) 180 Trace Status OFF OFF Note that each LAN monitor process is in the STARTED state.
Example: Displaying Detailed Status for a LAN Monitor Process This is an example of the SCF STATUS MON command with the DETAIL option: -> STATUS MON $ZZLAN.#ZLM00, DETAIL SLSA Detailed Status MON \FUDD.$ZZLAN.#ZLM00 Heap Memory Limit........ Heap Memory Used......... PID...................... Priority................. QIO Pool Current......... QIO Pool Limit........... State.................... Trace Filename........... Trace Status.............
Example: Verifying That the ADAPTER Object for an E4SA CRU Is Started This is an example of the SCF STATUS ADAPTER command: ->STATUS ADAPTER $ZZLAN.E0153 SLSA Status ADAPTER Name $ZZLAN.E0153 State STARTED Note that the ADAPTER object is in the STARTED state.
Example: Displaying Detailed Status for an Adapter This is an example of the SCF STATUS ADAPTER command with the DETAIL option for an Ethernet 4 ServerNet adapter: -> STATUS ADAPTER $ZZLAN.E0153, DETAIL SLSA Detailed Status ADAPTER \FUDD.$ZZLAN.E0153 SP Cru Presence Status... Enabled ( 5 ) SP Cru Test Status....... Config OK ( 0x0006 ) State....................
Example: Verifying That the SACs for an E4SA CRU Are Started This is an example of using the SCF STATUS SAC command: ->STATUS SAC $ZZLAN.E0153.* SLSA Status SAC Name $ZZLAN.E0153.0 $ZZLAN.E0153.1 Owner 0 0 State STARTED STARTED Note that the ServerNet addressable controllers (SACs) are in the STARTED state.
Example: Displaying Detailed Status for a SAC This is an example of the SCF STATUS SAC command with the DETAIL option: -> STATUS SAC $ZZLAN.E0153.1, DETAIL SLSA Detailed Status SAC \FUDD.$ZZLAN.E0153.1 Current Access........... Last Download Time....... Last Error............... Owner CPU................ State.................... Trace Filename........... Trace Status............. ( 0, 1 ) 02 Nov 1998, 17:32:10.135 (0, 0, 0) 1 STARTED OFF Current Access lists the processors in the access list.
Example: Verifying That a PIF Is Started This is an example of the SCF STATUS PIF command: -> STATUS PIF $ZZLAN.E0153.1.A SLSA Status PIF Name $ZZLAN.E0153.1.A State STARTED Note that the PIF is in the STARTED state.
Example: Displaying Detailed Status for a PIF This is an example of the SCF STATUS PIF command with the DETAIL option: -> STATUS PIF $ZZLAN.E0153.1.A, DETAIL SLSA Detailed Status PIF \FUDD.$ZZLAN.E0153.1.A CPUs with Data Path...... Interface Status......... Last Error............... State.................... Trace Filename........... Trace Status............. ( 0, 1 ) (3, LANMON, 2038) STARTED OFF E4SA-Specific Information: Link Pulse State......... UP TRSA-Specific Information: Ring State ...............
Last Ring Status is the current interface status of the token ring. Duplex indicates whether the line if full or half duplex. Line Speed indicates the line speed.
Example: Verifying That a LIF Is Started This is an example of the SCF STATUS LIF command: -> STATUS LIF $ZZLAN.L018 SLSA Status LIF Name $ZZLAN.L018 State STARTED Access State UP Note that the LIF is in the STARTED state and the access state is UP.
Example: Displaying Detailed Status for a LIF This is an example of the SCF STATUS LIF command with the DETAIL option: -> STATUS LIF $ZZLAN.LAN01, DETAIL SLSA Detailed Status LIF \FUDD.$ZZLAN.LAN01 Access State............. CPUs with Data Path...... Potential Access CPUs.... State.................... Trace Filename........... Trace Status.............
Verifying a SLSA Adapter You can use OSM Service Connection or the TSM Service Application to perform various tests on SLSA adapters. The SLSA adapter tests are: ● ● ● Responsive Test (in OSM) or SAC Responsive Test (in TSM) This online test action is provided for SACs on E4SA, CCSA, FESA, GESA, and TRSA CRUs and for the ATM3SA CRU. It verifies the integration of the SAC with the SLSA subsystem and verifies that the SAC is owned and is accessible.
If a test action fails, an error ID is returned. Recovering from an error ID is described in Correcting SLSA Adapter Problems.
Correcting SLSA Adapter Hardware Problems Note: The following instructions are applicable to the OSM package or the G06.02 and later versions of the TSM package. If a test action fails, an error ID is returned. From the Actions dialog box, click Show detail to display a brief explanation of the error. For more detailed information on how to recover from a specific error, click the error ID in the following table.
ServerNet Adapter Plug-In Cards (PICs). Error ID 6000004 This error is returned when the adapter is not in the STARTED state. To recover from this error, start the adapter and then retry the test action. Error ID 6000005 This is an internal error. There is no recovery. Contact the GCSC if this error occurs. Error ID 6000006 The power-on self-test (POST) failed. The failed LED will be set on the adapter. To recover from this error, you must replace the adapter.
This error is returned when the object on which the test action was requested has not been configured. To recover from this error, configure the object by using SCF commands and then retry the test action. Error ID 6000018 This error is returned when no ServerNet addressable controllers (SACs) are found on the CCSA adapter. A SAC resides on a CCSA as a plug-in card (PIC). To recover from this error, make sure that at least one PIC is properly inserted in the CCSA.
Verifying LAN Hardware for a SLSA Adapter Verifying the local area network (LAN) hardware used by a ServerNet LAN Systems Access (SLSA) adapter involves standard networking troubleshooting techniques such as checking Ethernet segments, Ethernet cables, and Ethernet hubs to isolate the location of a failure. The statistics gathered by the SCF STATS command might help you diagnose and isolate a LAN hardware problem.
Correcting a LAN Hardware Problem for a SLSA Adapter Correcting problems with the local area network (LAN) hardware used by a ServerNet LAN Systems Access (SLSA) adapter involves standard network troubleshooting techniques such as replacing cables and Ethernet hubs.
