| System Management Services (SMS) 1.5 Release Notes |     |
| System Management Services (SMS) 1.5 Release Notes | |
| C H A P T E R 2 |
|
SMS 1.5 Bugs |
This chapter provides information about known SMS 1.5 bugs, as well as bugs that have been fixed in the SMS patches that support the UltraSPARC IV+ processor. The chapter includes the following sections:
This section lists the bugs in SMS 1.5 software and related bugs that have been fixed in the SMS patches that support the UltraSPARC IV+ processor.
|
Note - Patch 120648-02 is required for UltraSPARC IV+ processor support. |
Patch 120843-01 enhances the error handling and recovery capabilities of OpenBoot
PROM to include the UltraSPARC IV+ processors.
After a card is hot-plugged into slot 1 (c5v0) and the system is restarted, prtdiag showed the correct bus frequency for the populated slot, but incorrectly reported the bus frequency for the other empty slots. This has been fixed in Patch 120843-01.
On Sun Fire E25K/E20K systems that have dual-core UltraSPARC IV+ boards installed, lpost might fail at diagnostic levels 64, 96, or 127. When the failure occurs, lpost returns the following error message:
Patch 120648-02 fixes this issue.
hpost in SMS 1.5 needs to be modified to support the UltraSPARC IV+ boards. Patch 120648-02 makes this modification.
Occasionally, a Sun Fire E25K/E20K system running the Solaris 9 4/04 OS on UltraSPARC IV+ boards will time out if you reboot a domain on the UltraSPARC IV+ board. The system returns the following error message:
Proccore SB0/P0/C0 timed out on test Domain Advanced Tests id=0x6F. Test Failed.FAIL Proccore SB0/P0/C0: test_seq_cwd(): failed out of config on timeout (Timeout Secs Given: 30) |
Patch 120648-02 fixes this issue.
The first UltraSPARC IV+ processors released for customer systems are version 2.1.1. Patch 120648-02 modifies POST to detect earlier version 2.1 processors, which are not qualified for customer use, and fail them out of the configuration.
Note that versions 2.1 and 2.1.1 cannot be discriminated by MaskID, which is 2.1 for both. POST discriminates them based on other electrically-readable information.
This bug applies only to 1500 MHz UltraSPARC IV+ boards. Occasionally, using the marginvoltage command with the -m-1 option returns an incorrect value. If you issue the command again a few seconds later, it returns the correct value. This has been fixed in Patch 120789-01.
This bug applies only to 1500 MHz UltraSPARC IV+ boards. When you use the
-m-1 or -m+1 options with the marginvoltage command, the system returns an incorrect output format. For example, using the -m+1 command returns a changed value of Nom (voltage) instead of Nom+3% (voltage) on the UltraSPARC IV+ boards, but the same command returns correct output on UltraSPARC IV and UltraSPARC III boards. Patch 120789-01 fixes this issue.
UltraSPARC IV+ processors include additional error detection and RAS capabilities beyond those in UltraSPARC IV and III+ processors. This CR describes an enhancement to the Availability functionality to diagnose the new errors an UltraSPARC IV+ can report. With this enhancement, Availability diagnoses all fatal errors for all processor types, as well as non-fatal errors for Solaris 9 domains. Patch 120827-01 provides this enhancement.
The UltraSPARC IV+ chips have three levels of cache. Levels 2 and 3 refer to data caches; Level 2 is internal to the processor, and Level 3 is external to the processor.
Sometimes an error produces additional error as side effects. When an error occurs in either level of the data cache, the Availability software diagnoses the root cause of the error and discards the side effect error (or errors). This not only aids in diagnosability, but also ensures that a victim component is not indicted due to a side effect error. Patch 120827-01 fixes this condition.
On a system running multiple domains, hwad must issue a dstop (domain stop) event to each of the running domains before dsmd can recover the domains after an error condition. Because these dstops were issued in series, there was a delay between the time that the initial dstop was issued and the time when all of the domains have been recovered.
Patch 120789-01 fixes this issue so that the dstops are now issued to the domains in parallel using separate threads, thus eliminating the delay.
To account for the additional cache level in the UltraSPARC IV+ processors, the SC-side SERD (Soft Error Rate Discriminator) required different threshold values to align with existing thresholds on Solaris 9 domain. Without the adjustment, the domain will offline the processor prior to the SC-side diagnosis, and the processor's health status is not updated correctly.
Patch 120827-01 fixes this issue so that diagnoses are consistent between the two operating system versions and SMS 1.5 software for all supported types of processors.
This section summarizes the most important bugs that affect SMS 1.5.
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 Sun Fire E25K/E20K 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, you 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. You 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 (for example, 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, you should not assume that hardware is the only possible cause of the asterisk.
This section summarizes errors in the SMS 1.5 man pages and documentation.
The marginvoltage man page states the following:
Margin settings are not persistent following power cycles.
That statement is true only for core voltages. All other settings are persistent.
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.
If you are running the Solaris 8 or Solaris 9 OS on the domain, perform the following check:
1. 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.
2. If the error is unrecoverable, you must reboot the domain in order to use that board.
If you are running the Solaris 10 OS on the domain, the dcs is now part of the SMF (Service Management Facility). Perform the following steps:
1. Make sure you are logged in as root.
2. Type the following command at the system prompt on the domain:
3. If the dcs is disabled as shown in the above example, enable it by typing the following command:
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 should read as follows:
A voltage core monitoring parameter (VCMON) was added to the SMS software. When VCMON is enabled, it monitors any voltage changes or drifts on the processors. If VCMON detects an upward change in voltage (which usually indicates a socket attach issue), it notifies the user with an FMA event and marks the component health status (CHS) of that processor as faulty.
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
The Hardware Compatibility Table (Table 2-1) should list Solaris 8 2/02 as the first supported version of Solaris 8 software for both the domains and the system controllers (SCs).
This table contains a typographical error; it refers to a 1.65 MHz UltraSPARC processor. The correct speed should be 1.5 MHz.
SMS 1.5 supports a /swap partition size of 2 Gbytes as well as the 4 Gbyte size described in the Installation Guide. The recommended partition sizes for SMS 1.5 are as follows:
SMS must be up and running before you can disable failover.
To verify that Java version 1.2.2 has been installed, type the command java -version at the system prompt.
Run the smsupgrade command to reinstall SMS.
SMS must be up and running before you can record the chassis serial number (CSN).
The example should show sc0, not sc1.
The flashupdate example is missing the -f switch. It should read as follows:
-f /opt/SUNWsms/hostobjs/sgcpu.flash
After Step 2, there should be a Step 3 in this procedure. Step 3 should read:
Upgrade the Solaris OS. See "To Install or Upgrade the Solaris OS on the SC" on page 17.
After Step 3, there should be a Step 4, which should read 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."
| System Management Services (SMS) 1.5 Release Notes | 817-7297-11 | |
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.