C H A P T E R 2 |
SMS 1.5 Bugs |
This chapter provides information about known SMS 1.5 bugs. It includes:
This section summarizes the most important bugs that affect SMS 1.5.
The smsrestore command will fail if there are more than 4095 files in the cpio archive.
The workaround is to remove unneeded files and recreate the cpio archive with smsbackup. The most likely candidates for unneeded files are post logs and dump files. There may be up to 1000 post logs per domain and up to 1000 dump files per domain.
If a Sun Fire high-end server runs without having its chassis serial number (CSN) set on the SCs using the setcsn command, any Fault Management Architecture (FMA) reports sent to NetConnect after a domain stop (Dstop) will show the serial number as blank in its event reports.
Workaround: Use the setcsn command to set the chassis serial number and then restart SMS. You must restart SMS in order for the CSN to appear in the event reports.
For more information about how to set the chassis serial number on the SC, refer to the System Management Services (SMS) 1.5 Installation Guide.
The ndd(1M) command can be executed as root in order to read and write certain device driver parameters. scman(7D) (ndd/dev/scman) manages the Starcat SC side of the Management (MAN) Network, and it supports the ndd(1M) command.
If the man_pathgroups_report parameter of scman(7D) is not interpreted correctly, it may appear as though a serious hardware error has occurred, when the error is actually caused by software. As a result, it might incorrectly be concluded that swapping of hardware is required in order to root-cause the problem.
When the man_pathgroups_report parameter is specified, one can obtain output such as the following:
The asterisk (*) in the last line denotes that "the last time the hme1 physical interface was used, an error was found". Historically, the majority of occurrences are due to software, not hardware.
Software causes an error when either the MAN network peer no longer responds to "heartbeat" messages, or when there is an incorrect dlpi(7P) state transition. One can repeatedly create the former case by running the following command as root (assuming the exact output appears as shown above):
For the SC that executes the command (eg, SC0), its Active Path is switched from eri0 to hme1. For a while, SC1 will continue to send packets on the eri0 physical interface, and SC0 will send packets on hme1. After a short while, the two will synchronize and communicate using the same interface. However, an asterisk will be shown (on each SC) to show the last interface on which there was an error. In this case, the error is indeed caused by software (that is, the error is really a non-response to a "heartbeat" message sequence). It is not a fatal hardware error.
An asterisk will indeed be shown in the output if there is a persistent, fatal hardware error. However, one should not assume that hardware is the only possible cause of the asterisk.
If you remove, install, and assign boards in Domain A on your Sun Fire system and then use the showenvironment command with the -d A option, the command returns an error message stating :
No board assigned to Domain A.
The error message is incorrect and can be ignored. This issue occurs only on Domain A.
This section summarizes errors in the SMS 1.5 man pages and documentation.
The Note in the rcfgadm(1M) man page should read as follows:
If the rcfgadm command fails, a board does not return to its original state. A dxs or dcs error message is logged to the domain. If the error is recoverable, you can retry the command.
Before you retry the command, ensure that the following dcs entries exist in /etc/inetd.conf on the domain, and that they have not been disabled:
If the error is unrecoverable, you must reboot the domain in order to use that board.
The description of the -c option in the testemail(1M) man page should read as follows:
The fault class or comma-separated list of fault classes that testemail uses to generate an event.
-c fault_class, fault_class, fault_class
Examples of valid fault classes are in the file /etc/opt/SUNWSMS/config/SF15000.dict .
The note in the Description section should read as follows:
When invoking testemail using an ecache resource, make sure that the system board containing the ecache is powered on. Otherwise, the testemail invocation will fail and no email will be generated.
The description of VCMON is incorrect for the Sun Fire high-end systems. The correct description appears in VCMON of this document.
In the description of the showboards command, the -a option should read -v.
In the description of the showenvironment command, the category "Device" should be removed.
The first example should read as follows:
showlogs -d domain_indicator -p s
The second example should read:
showlogs -d domain_indicator -p c
The following commands should be added:
smsinstall: Installs the SMS software.
smsupgrade: Upgrades the existing SMS software installed on a system.
Appendix B (CRs 6227544, 4943474):
The following categories of error messages should be added between error codes 11300 and 50000:
11500-11699: Reserved for EFHD messages
11700-11899: Reserved for ELAD messages
11900-12099: Reserved for ERD messages
12100-12299: Reserved for Event Utilities messages
12300-12499: Reserved for Wcapp messages
12500-12699: Reserved for FRUID-related messages
12700-12799: Reserved for EBD messages
Run the smsupgrade command to reinstall SMS.
Upgrade the Solaris OS. See "To Install or Upgrade the Solaris OS on the SC" on page 17.
After Step 4, there should be a Step 5, which reads as follows:
Run smsupgrade to reinstall SMS after a major OS upgrade (see page 34). Otherwise, proceed to the next step and restore the SMS configuration.
The heading "To Reinstall SMS Software" should read "To Restore the SMS Configuration."
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.