A P P E N D I X  A

Warning and Information Messages

This appendix explains the XSCF fault and informational messages output during the operation with the console, mail, or SNMP function of the server.


A.1 Message Types

The Oracle Solaris OS outputs this message to the domain console. For instructions on how to reference syslog messages, see the Oracle Solaris OS documentation.

The FMA message describes the results of a diagnosis automatically generated for hardware or software faults by the server’s Fault Management Architecture (FMA) fault management facility. When this message is output to the domain console, the user can identify the portion corresponding to the notified fault in the server. The FMA message is retained as log information (in a fault log or error log). The Oracle Solaris fmdump(1M) command or the fmdump(8), or showlogs(8) command of the XSCF Shell can be used to display the message contents for more detailed investigation. The user can also confirm the contents by using the specified URL based on the MSG-ID displayed on the console.

This message is output during the system startup. The IPL message is output to the domain console and retained as log information (in an IPL log) in the XSCF. The IPL log retains the information corresponding to the last single system startup for each domain. The showlogs(8) command of the XSCF Shell can be used to display the IPL log.

This message is output in case of panic. The panic message is output to the domain console and retained as log information in the XSCF. The panic log retains the information corresponding to the last single panic event that occurred. The showlogs(8) command of XSCF can be used to display the panic log.

The console message is a general term used to describe syslog messages, FMA messages, panic messages, IPL messages, and other messages output by POST, OpenBoot PROM, and the Oracle Solaris OS. The console messages are output to each domain console and are retained as log information (in a console log) in the XSCF. The showlogs(8) command of the XSCF Shell can be used to display the console log.



Note - Console messages are overwritten, beginning with the oldest message. Even when the wraparound feature causes a console message to be overwritten, the system startup message is retained in the IPL log, and in case of panic, the log is retained in the panic log.
When the XSCF unit is redundant, the console messages retained in the XSCF Unit on the active side are not copied to the standby side. Accordingly, after the XSCF Unit is switched, the console messages on the previously active side cannot be referenced.


The XSCF firmware outputs this message to notify the server fault or status. The monitoring message is output by using the showmonitorlog(8) command, and retained as log information (in a monitor message log or XSCF error log) in the XSCF. The showlogs(8) command of the XSCF Shell can be used to display the monitoring message and XSCF error log for more detailed investigation. Authorized service personnel use the DIAGCODE output in the message to acquire detailed information.



Note - Monitoring messages are overwritten, beginning with the oldest message. When the XSCF Unit is redundant, monitoring messages output by the XSCF Unit on the active side are also managed on the standby side. Even after the XSCF Unit is switched, the monitoring messages on the previously active side can be referenced.


In addition to the messages above, there is a notification message displayed on the domain console when power off or reset processing is performed normally or an event occurs.


A.2 Messages in Each Function

This section explains each Oracle Solaris OS and XSCF function by which the user can recognize status notification or fault information in the server, including messages.

Recognizing Status Notification or Fault Information by a Message on the Domain Console

1. The user recognizes status notification or fault information in a console message such as a syslog message and FMA message output to the domain console. The following shows an example of the FMA message on the domain console.


<Example>  FMA Message 
SUNW-MSG-ID: SUN4U-800J-C0, TYPE: Fault, VER: 1, SEVERITY: Critical
EVENT-TIME: Wed Jun 28 17:45:36 PDT 2006
PLATFORM: SUNW,SPARC-Enterprise, CSN: -, HOSTNAME: dc102
SOURCE: eft, REV: 1.5
EVENT-ID: 24fe9f8c-f302-4128-c5b8-b38a4083769f
DESC: The number of errors associated with this CHIP has exceeded acceptable
levels. Refer to http://sun.com/msg/SUN4U-800J-C0 for more information.
  Refer to SUN4U-800J-C0 for more information.
AUTO-RESPONSE: An attempt will be made to remove the affected CHIP from
service.
 
IMPACT: The system will not be functioning at the same performance level with
the CHIP removal.
 
REC-ACTION: Schedule a repair procedure to replace the affected CHIP. Use
fmdump -v -u to identify the smallest CPU/Strand ID of the affected CORE on
this CHIP.



Note - The message format may change in future releases.


2. Fault information in the FMA message is stored in the log. Therefore, the log file can be referenced on the domain console. Perform an Oracle Solaris OS command such as the syslog reference command or fmdump(1M) command on the domain console. For how to identify fault information by using these commands, see the Oracle Solaris OS documentation.

3. The contents of notification or fault information can be confirmed by accessing the specified URL according to the message ID (SUNW-MSG-ID) displayed on the domain console. If no message ID (MSG-ID) is found, acquire detailed information from the syslog information.

4. To acquire more detailed information, log in to the XSCF and perform the fmdump(8) or showlogs(8) command to identify the fault information. For details of these two commands, see Appendix B.

5. Repair the fault according to processing recommended by the information provided on the specified URL (Note).

In some cases, the user may recognize the fault by referring to the console messages, panic messages, IPL messages, or monitoring messages stored in the XSCF log. The showlogs(8) command of the XSCF Shell with each log option specified can be used to reference this log information.



Note - For up-to-date URL information, see the web site information about the messages listed in the Product Notes for your server.


Recognizing a Fault in a Message Reported by Email

1. The user recognizes status notification or fault information as the Subject of the email reported by XSCF or in the text of the message. For an example of a mail message, see Chapter 6.

2. According to the displayed message ID (MSG-ID), the user can access the specified URL to confirm the information. Authorized service personnel can use the DIAGCODE output in the message to acquire detailed information.

3. To obtain more detailed information, log in to the XSCF and perform the fmdump (8) or showlogs(8) command to identify the fault information.

4. Repair the fault according to the processing recommended by the information provided on the specified URL.

Recognizing Status Notification or Fault Information in an SNMP Trap Message

1. The user recognizes status notification or fault information in the trap information issued by the SNMP manager from the XSCF. The contents of the report are the same as those of email.

2. Perform Step 2 to Step 4 above in "Recognizing a Fault in a Message Reported by Email".

Recognizing Status Notification or Fault Information in a Monitoring Message on the XSCF Shell Terminal

1. The user recognizes status notification or fault information in a XSCF monitoring message output by using showmonitorlog(8) comannd. The following shows an example of the XSCF monitoring message.


Jun 16 12:20:37 JST 2005 FF2-5-0:Alarm:/CMU#0/CPU#0:XSCF:Uncorrectable error
( 80006000-20010000-0108000112345678)

(The example is subject to change without previous notice for functional improvement.)

2. To obtain more detailed information, specify the error option and perform the showlogs(8) command to identify fault information.

3. In the XSCF error log, confirm the contents of entry corresponding to the fault. (See Appendix B.)

4. Specify the error detail option in showlogs(8) to display the message ID (MSG-ID). The information can be confirmed by accessing the specified URL according to the displayed message ID (MSG-ID). Authorized service personnel use the DIAGCODE (Code) output in the message to acquire more detailed information.

5. Repair the fault according to the processing recommended by the information provided on the specified URL.