- Network Parameters
- Critical OpenBoot PROM Configuration Parameters
- Time and Date
- Host Watchdog, Rocker Switch, and Secure Mode Settings
- Password Management
- Firmware Upgrades
- Error Logging
- Error Analysis
- LED Status and Alarms
- Environment Monitoring and Control
- Console Navigation
- Power Failure and Recovery Behavior
- Precautions for Using the SCC
- System Controller Configuration Backups
- Power Connections for Redundancy and Grounding
- Rackmounting and Improving Serviceability
- References
- Acknowledgements
- About the Author
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Error Logging
You should install the Lights-Out-Management 2.0 packages (SUNWlomu, SUNWlomr, and SUNWlomm) from the Software Supplement CD. The LOM software enables you to configure and monitor the system using the LOM commands from the Solaris OS prompt. Refer to the Sun Fire V1280/Netra 1280 Product Notes for the latest information on required patches.
Briefly, the error logging features are:
Log listing from the Solaris OS (lom -e)
Log message delivery to the Solaris OS (syslogd(1M) and /var/adm/messages)
Message printing control at the SC prompt when the Solaris OS is running
Configuration of the Solaris OS reporting level from the Solaris OS (lom -E)
Logged message retrieval on the Solaris OS boot
The SC has an error buffer that is 128 kilobytes. The maximum length of the log message that gets sent to the Solaris OS is 1012 bytes. The maximum number of messages that can be stored in the error buffer is 128.
Because there is no nonvolatile storage on the IB_SSC, all of the messages go to the domain (that is, the running instance of the Solaris OS) through an internal SC-to-domain communication mechanism. The messages are immediately stored in /var/adm/messages. Although there is no log host facility to send information directly from the SC to an external log host, it is possible to set up an external log host on the network and to get the information sent to it from syslogd(1M) on the running domain.
There is a small window of vulnerability after the domain crashes and before the domain restarts in which a power outage or an SC reset would cause the SC data to be lost because the messages cannot be logged in /var/adm/messages on the domain. This can become a problem when you have a Solaris OS crash and a subsequent SC reset and a power outage at the same time. It is technically not possible to overcome this limitation. The only way to reduce the risk is to ensure that the SC does not lose power at the same time when there are problems with the domain.
When you are at the lom> prompt, the display of the messages on the shared Solaris OS and SC console port is controlled by the seteventreporting command. This command determines whether a message is printed at the lom> prompt at the time the message is logged or whether it is posted to the Solaris OS logging system (that is, written to the /var/adm/messages file).
The following example shows how to set the reporting level and to display the current settings:
lom> seteventreporting on 3 lom> showeventreporting eventreporting is default reporting level is 3 Event reporting levels map to the following: (0) - Event reporting level=none (1) - Event reporting level=fatal (2) - Event reporting level=fatal & warning (3) - Event reporting level=fatal, warning & information (4) - Event reporting level=fatal, warning, information & user
The event reporting levels control the level of messages offered to the Solaris OS. The higher levels of reporting cause more messages to be displayed. What the Solaris OS does with them is controlled by syslogd(1M). The messages are put in the /var/adm/messages file by default.
The event reporting level should be configured to at least Level 3 so that critical information is available for failure analysis. Level 4 does not currently have any significance and operates as Level 3.
LOM event reports can interfere with the information you are attempting to send or receive on the console. You can stop the LOM software from sending reports to the console by using the following command:
# lom -E off
To prevent LOM messages displaying when you are at the lom> prompt, turn off serial event reporting. This is equivalent to using the seteventreporting command. You can turn serial event reporting on again by using the following command:
# lom -E on