Problems Resolved in XCP 2070
Problems Resolved in XCP 2070
The following table lists the problems resolved in XCP 2070.
| RTI No. | RTIF2-210209-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When downloading a PCI expansion unit firmware image from XSCF Web, in some very rare cases, "Loading" remains displayed and the browser is unresponsive. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-210104-005 |
| Model | SPARC M10-4S |
| Description | If an error occurs with the SP to SP communication protocol (SSCP), you may be unable to execute the deleteboard -c unassign command. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-210104-007 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When using XSCF Web in Internet Explorer, the browser does not respond after you select and execute [Restore] or [Restore CoD Key] from [Maintenance] - [Configuration Management] menu. |
| Workaround | There is no effective workaround. Execute the restoreconfig and restorecodactivation commands. |
| RTI No. | RTIF2-210104-011 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If a failure occurs in a PCI expansion unit, the SNMP Trap of scfComponentStatusEvent for notification of the FRU status is not sent. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-210104-012 |
| Model | SPARC M10-4S |
| Description | Immediately after the poweron -a command is executed on the system connected to a crossbar box, the forced power-off of one physical partition (PPAR) may mistakenly power off all PPARs. |
| Workaround | If forced power-off of a PPAR is necessary, do so after executing the showlogs power command and confirming that all crossbar boxes are powered on. [Power log example] In a system with four crossbar boxes connected, all the crossbar boxes are powered on. Mar 20 15:16:19 JST 2020 PPAR Power On Operator 00 Locked Mar 20 15:16:40 JST 2020 Cabinet Power On Operator 81 Locked Mar 20 15:16:40 JST 2020 Cabinet Power On Operator 80 Locked Mar 20 15:16:40 JST 2020 Cabinet Power On Operator 82 Locked Mar 20 15:16:40 JST 2020 Cabinet Power On Operator 83 Locked |
| RTI No. | RTIF2-201215-004 |
| Model | SPARC M10-4S |
| Description | If the XSCF BB control cable is not connected or has failed, XSCF master/standby switching may not be possible, even when the XSCF DUAL control cable is normal. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201215-005 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The showpparprogress command may not display the message "The sequence of power control is completed" even after the power-on of a physical partition (PPAR) is completed. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201215-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the initial diagnosis by POST detects a memory failure, the registered suspected location in the error log may be wrong. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201215-010 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Due to a power failure, a physical partition (PPAR) may not be powered off but remain powered on. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201215-014 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If a Trap event occurs immediately after OS boot starts, OpenBootPROM may not stop displaying the errors, preventing OS boot in rare cases. |
| Workaround | There is no effective workaround. [How to restore] Execute the reset command to reset the logical domain. |
| RTI No. | RTIF2-201215-015 |
| Model | SPARC M10-4S |
| Description | Suppose that an XSCF internal error occurs in a system with a building block configuration while the physical partition (PPAR) is powered off. Then, after XSCF master/standby switching is completed, the PPAR cannot be powered on for about 20 minutes. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201215-016 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | An overwrite confirmation message may appear during firmware image file download from XSCF Web even though the file does not exist. Conversely, the overwrite confirmation message may not appear even though the file exists. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-201127-002 |
| Model | SPARC M10-4S |
| Description | When a physical partition (PPAR) is powered on in a system with a building block configuration, an XSCF panic may occur in rare cases. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140623-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Even when the snapshot(8) command is executed, it does not collect log data concerning NTP-related statistics. |
| Workaround | There is no effective workaround. This problem does not affect system operation. |
| RTI No. | RTIF2-131213-014 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the XSCF time zone is changed by the settimezone(8) command, the time zone of Oracle Solaris on that physical partition booted after the change is shifted (misaligned) by the time difference before and after the XSCF time zone change. [Example] If the time zone before setup was UTC and after setup is JST, the time misalignment of Oracle Solaris will be 9 hours. |
| Workaround | There is no effective workaround. Boot the Oracle Solaris after executing the resetdateoffset(8) command and set to the right time on the Oracle Solaris. |
| RTI No. | RTIF2-131112-010 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If you execute the XSCF commands in the following order, the setting information for the setntp(8) or settelnet(8) command is not applied and may return to the original state. 1. Execute any of the sethostname(8), setnameserver(8), setnetwork(8), setroute(8), or setsscp(8) command. 2. Execute either the setntp(8) or settelnet(8) command. 3. Execute the applynetwork(8) command. |
| Workaround | After executing any of the sethostname(8), setnameserver(8), setnetwork(8), setroute(8), or setsscp(8) command is executed, do not execute the setntp(8) or settelnet(8) command until the applynetwork(8) command is executed and the settings are applied. |
| RTI No. | RTIF2-131112-016 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If you use the deleteuser(8) command to delete a user account for which an SSH user public key is registered, it is deleted but the user public key is not deleted. User public keys will continue to increase in number such that it may not be possible to register one for a new user account. Moreover, if a user account with the same name is registered again, the SSH user public key registered previously is set. |
| Workaround | Before deleting a user account with the deleteuser(8) command, execute setssh -c delpubkey -a -u to delete the SSH user public key registered for the user account. [How to restore] Perform the following procedure. 1. Execute the adduser(8) command to register the deleted user account again. 2. Execute the rebootxscf -a command to reset the XSCF, or turn off and on the input power. 3. Execute setssh -c delpubkey -a -u to delete the SSH user public key. 4. Execute the deleteuser(8) command to delete the user account. |
| RTI No. | RTIF2-131108-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the "SCF Diagnosis initialize RTC" error occurs, or if the motherboard unit (MBU) is replaced with the SPARC M10-1 and the CPU memory unit lower (CMUL) is replaced with the SPARC M10-4/M10-4S, the following phenomena may occur. - Symptom 1 The XSCF time may return to January 1, 2001. - Symptom 2 The time difference between the XSCF and all physical partitions (PPARs) may become a value of 400 million seconds or more. You can check this phenomenon by executing the showdateoffset(8) command, since the time difference between the XSCF and all PPARs is displayed as a value of "400000000 sec" or more. XSCF> showdateoffset -aPPAR-ID Domain Date Offset00 400000100 sec01 400000100 sec: : 15 400000100 sec- Symptom 3 When you reset the PPAR or power cycle the PPAR, the Oracle Solaris time may return to January 1, 2001. |
| Workaround | There is no effective workaround. Update to firmware version XCP 2221 or later. [How to restore] See "Restoration After the "SCF Diagnosis initialize RTC" Error (RTIF2-131108-001)." |
| RTI No. | RTIF2-131004-001 |
| Model | SPARC M10-1 |
| Description | If firmware update is executed when the physical partition (PPAR) is powered on, the "CPU-MBC interface fatal error" error which is related to the motherboard unit (MBU), is mistakenly detected and may be registered in the error log. This mistaken detection may lead to stopping of the logical domains. |
| Workaround | Execute firmware update when the physical partition (PPAR) is powered off. |
| RTI No. | RTIF2-131004-002 |
| Model | SPARC M10-4S |
| Description | If, in a system configured with 3 BB or greater, the chassis of the master XSCF and the standby XSCF are turned off and then on again, the system enters a state in which there is no master XSCF. If the master XSCF is stopped while the XSCF DUAL control cable is either faulty or not connected, master/standby XSCF switching is suppressed, so that the standby XSCF is not switched to the master XSCF. |
| Workaround | There is no effective workaround. Update to firmware version XCP 2070 or later. |
| RTI No. | RTIF2-131004-003 |
| Model | SPARC M10-4S |
| Description | If master/standby XSCF switching occurs while the XSCF DUAL control cable is either faulty or not connected, switching may be performed even though communication between the master and standby is not guaranteed. If an XSCF is configured and master/standby XSCF switching is performed while the XSCF DUAL control cable is either faulty or not connected, the information set in the XSCF will be erased. |
| Workaround | There is no effective workaround. Perform master/standby XSCF switching while the XSCF DUAL control cable is connected normally. Whether the XSCF DUAL control cable is connected normally can be confirmed with the following procedure. 1. Execute the showsscp -a command. 2. Check that, in the output results obtained in Step 1., "Cannot communicate." is not displayed for the Address for which the SSCP link network ID (network_id) is 2 or 4. [Example] If there is no crossbar box, confirm the Address with an SSCP link network ID (network_id) of 2. XSCF> showsscp -a -N 2 : : Location Address ------------- --------------- bb#00-if#2 169.254.1.17 bb#01-if#2 169.254.1.18 Similarly, if there is a crossbar box, confirm the Address with an SSCP link network ID (network_id) of 4. |
| RTI No. | RTIF2-130930-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If, in an environment for which a time zone is set for the XSCF and daylight saving time is introduced, a physical partition (PPAR) is restarted or a PPAR is turned off and then on again, the start time of the logical domain may be advanced or delayed for 3600 seconds or longer. This can be confirmed by executing the showdateoffset(8) command. In the following execution example, the time difference between the PPAR and XSCF is +/-3600 seconds or greater, indicating that this defect has occurred. [Example] XSCF> showdateoffset -aPPAR-ID Domain Date Offset00 -7205 sec01 -7205 sec02 -7205 sec03 -7205 sec04 -7205 sec05 -7205 sec06 -7205 sec07 -7205 sec08 -7205 sec09 -7205 sec10 -7205 sec11 -7205 sec12 -7205 sec13 -7205 sec14 -7205 sec15 -7205 sec |
| Workaround | There is no effective workaround. For every logical domain in the system, make the settings so that they can be synchronized with the NTP server time. If the start time of a logical domain shifts, correct the time via NTP. |
| RTI No. | RTIF2-130903-002 |
| Model | SPARC M10-4S |
| Description | In a system consisting of multiple SPARC M10-4S units, it may take longer than usual from the time a physical partition (PPAR) is turned on until the Power-On Self-Test (POST) starts. For example, for a 2BB configuration, POST usually starts after about 10 minutes, but it may take 20 minutes or longer. |
| Workaround | There is no effective workaround. If this defect occurs, execute the rebootxscf -a command to reset all the XSCFs and restore the system. |
| RTI No. | RTIF2-130903-006 |
| Model | SPARC M10-4S |
| Description | If multiple physical partitions (PPARs) exist in a system consisting of multiple SPARC M10-4S units, and some SPARC M10-4S units are turned off and then on again, an "SRAM Serious Error" may occur, requiring the replacement of the CPU memory unit lower (CMUL). When the state is displayed with the showpparstatus(8) command or the showdomainstatus(8) command, the PPAR state may not be displayed correctly. |
| Workaround | There is no effective workaround. While a PPAR is operating, do not turn off the SPARC M10-4S. Use the poweroff(8) command, for example, to stop a PPAR before turning it off. |
| RTI No. | RTIF2-130903-007 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the setcod(8) command is executed repeatedly on the physical partition (PPAR) in the PowerOn state, the resources available within the process may be exhausted, and codd may cause a "process down." |
| Workaround | You can avoid this by executing setcod(8) when PPAR is in the PowerOff state. [How to restore] Restart codd. |
| RTI No. | RTIF2-130903-008 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If any device is specified with the select command of OpenBoot PROM first but the unselect-dev command is not executed and subsequently the boot command is used to start Oracle Solaris from a network device, then the following defect occurs. On the console of the logical domain, the "seek failed" and "Can't mount root" messages are displayed, and the starting of Oracle Solaris fails. Then, the "I/O device error detected" message is registered in the error log, and the logical domain is reset. After the logical domain is reset, the device specified with the select command is degraded. After the reset, the logical domain enters either of the following states depending on the setting of the OpenBoot PROM environment variable "auto-boot?". - If auto-boot? is true Oracle Solaris is started from the device that is set as the boot-device. If, however, the device specified with the select command, above, is the same as the device that has been set as the boot-device, this device is degraded, so that Oracle Solaris will fail to start, and the ok prompt appears. - If auto-boot? is false The ok prompt appears, in the same way as in normal operation. |
| Workaround | After specifying a device and executing the select command, be sure to execute the unselect-dev command before executing the boot command. [Example] {0} ok select /pci@8000/pci@4/pci@0/pci@1/network@0 {0} ok unselect-dev {0} ok boot net [How to restore] - If, after the defect occurs, the logical domain is in the ok prompt state Execute the following command to reset the logical domain. {0} ok reset-all - If, after the defect occurs, Oracle Solaris has been started in the logical domain Use the shutdown command to first enter the ok prompt state and then set environment variable auto-boot? to false. Then, use the reset-all command to restart OpenBoot PROM. [Example] # shutdown -y -g0 -i0 {0} ok setenv auto-boot? false {0} ok reset-all After recovery, any device that was degraded as a result of this defect will be recognized normally. Ignore the message registered in the error log when the defect occurred. |
| RTI No. | RTIF2-130902-001 |
| Model | SPARC M10-4S |
| Description | If the firmware is updated while a logical domain is operating in a system consisting of multiple SPARC M10-4S units, the master XSCF may not switch to a standby XSCF, causing the firmware update to fail. |
| Workaround | There is no effective workaround. Recover the system by following the procedure described below. 1. Log in to either standby XSCF, and then execute the following command. XSCF> rebootxscf -s 2. After 10 seconds, log in to the other standby XSCF, and then execute the following command. XSCF> rebootxscf -a 3. Wait 20 minutes, log in to the master XSCF, and then execute the flashupdate(8) command again. |
| RTI No. | RTIF2-130826-001 |
| Model | SPARC M10-4S |
| Description | If you log in to XSCF Web from the master XSCF when the standby XSCF is in either the maintenance or input power off state, a dialog box starting with "Cannot communicate with BB#xxx: ..." is output, indicating a non-breaking communication error. |
| Workaround | There is no effective workaround. The message in the dialog indicates a display defect, so you can operate the system as is. Ignore the dialog related to this communication error. |
| RTI No. | RTIF2-130802-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When you specify USB memory for the getflashimage(8) command, the following message may be output and the execution of the command may fail. Error: Unable to mount USB device. |
| Workaround | After disconnecting and then connecting the USB memory, execute the getflashimage(8) command again. |
| RTI No. | RTIF2-130802-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When Oracle Solaris is operating, if you change the SNMP setting with the setsnmp(8) command, the following phenomena may occur. 1. A part of the data such as the XCP version number is not output as a result of the prtpicl -v and prtdiag -v commands. 2. To /var/adm/messages of Oracle Solaris, the following warning message is output. PICL snmpplugin: cannot fetch object value |
| Workaround | There is no effective workaround. - If 1. occurs: Recover with the following procedure. 1) End the prtdiag command with [Ctrl] + [C]. 2) Wait about 30 minutes to allow an SNMP timeout to occur on the XSCF. 3) On the logical domain, execute the svcadm command to restart the picl service. - If 2. occurs: The system can be operated continuously because this is a temporary warning message. |
| RTI No. | RTIF2-130801-001 |
| Model | SPARC M10-4S |
| Description | Even if you execute the switchscf(8) command, the XSCF may not be switched. At this time, the master XSCF and standby XSCF cannot communicate with each other, and the redundancy of the XSCF is not maintained. |
| Workaround | There is no effective workaround. If the XSCF is not switched even by executing the switchscf(8) command, execute the replacefru(8) command to perform active replacement of the XSCF unit that is in the standby chassis. Also, when you disconnect the XSCF unit, disconnect and then connect the XSCF BB control cable. |
| RTI No. | RTIF2-130716-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When you update the PCI expansion unit firmware by executing the ioxadm(8) command, a "LINKCARD I2C error" error may occur. |
| Workaround | There is no effective workaround. However, if both of the conditions below can be confirmed, the update of the PCI expansion unit firmware has been completed normally. In this case, ignore the "LINKCARD I2C error" error message, and continue the operation. - The update of the PCI expansion unit firmware by using the ioxadm(8) command has been completed normally. - Executing the ioxadm -v list command displays the version number of the PCI expansion unit firmware that has been specified for the update. |
| RTI No. | RTIF2-130711-001 |
| Model | SPARC M10-4S |
| Description | When you perform maintenance of the SPARC M10-4S by executing the replacefru(8) or addfru(8) command, the "FMEM serious error" error log may be registered and the replacefru(8) or addfru(8) command may fail. Also, when you turn on the power to the physical partition (PPAR) during the execution of the flashupdate(8) command, similarly, the "FMEM serious error" error log may be registered and the flashupdate(8) command may fail. |
| Workaround | For details, see "Response to "FMEM serious error" of the SPARC M10-4S (RTIF2-130711-001)." |
| RTI No. | RTIF2-130709-001 |
| Model | SPARC M10-4S |
| Description | In the state where the physical partition (PPAR) is powered on, when switching of the master XSCF occurs, it may take time before the standby XSCF switches to the master XSCF. As a result, the following error may occur: Master switch synchronization timeout |
| Workaround | There is no effective workaround. [How to restore] - If the error occurs during execution of the flashupdate(8) command when the power to the PPAR is on: Turn off the power to the PPAR, and then execute the flashupdate(8) command again. - If the error occurs during execution of the switchscf(8) command when the power to the PPAR is on, or if the error occurs due to an XSCF failure ("process down," etc.) when the power to the PPAR is on: Perform recovery of the SPARC M10-4S chassis for which the "XSCF hang-up is detected" error log has been registered by using either of the following methods. - Execute the replacefru(8) command to replace the CPU memory unit lower (CMUL) or XSCF unit (XSCFU). - Power off and on the CPU memory unit lower (CMUL) or the XSCF unit (XSCFU). |
| RTI No. | RTIF2-130516-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In a system configuration for which remote power management with the ETERNUS is set, the ETERNUS is not powered on even if the power is turned on from the power switch located on the operation panel of the SPARC M10 system. |
| Workaround | Turn on the power in one of the following ways: - XSCF command, poweron(8) command - Menu on the page of XSCF Web - Automatic power turning on with schedule settings |
| RTI No. | RTIF2-130228-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If a physical partition (PPAR) is powered on again after the PPAR is forcefully powered off with the poweroff -f command while starting up Oracle Solaris, "Unable to connect to Domain Service providers" is output to the OS console and Oracle Solaris may not be started. |
| Workaround | Power on the PPAR again with the poweron(8) command after disconnecting the power of the PPAR with the poweroff(8) command. If Oracle Solaris does not start up even after that, reset the XSCF after disconnecting the power of the PPAR and then power on the PPAR again. |
Response to "FMEM serious error" of the SPARC M10-4S (RTIF2-130711-001)
- Replacing the SPARC M10-4S
When replacing the SPARC M10-4S by following the maintenance menu displayed by executing the replacefru(8) command, perform Step 3 and then turn on the input power to the target SPARC M10-4S (BB#x). Then, after waiting for 50 minutes, manually enter "f" in Step 4 to perform the work.
Please execute the following steps: |
- Adding SPARC M10-4S
When adding the SPARC M10-4S by following the maintenance menu displayed by executing the addfru(8) command, perform Step 1 and then turn on the input power to the target SPARC M10-4S (BB#x). Then, after waiting for 50 minutes, manually enter "f" in Step 2 to perform the work.
Please execute the following steps: |
- Executing the flashupdate(8) command
Do not power on the physical partition (PPAR) during the execution of the flashupdate(8) command. If you power on the PPAR during the execution of the flashupdate(8) command, power it on again after the completion of the command. Upon the completion of the flashupdate(8) command, execute the showlogs event command to confirm the following message.
|
Restoration After the "SCF Diagnosis initialize RTC" Error (RTIF2-131108-001)
[How to restore]
- If phenomenon 1 occurs: - Case 1If the Oracle Solaris time has returned to January 1, 2001, execute the setdate(8) command to set the XSCF time again. In this case, the XSCF is rebooted. After that, power cycle the PPAR. After this, the XSCF is reset. After that, power on the PPAR.- Case 2If the Oracle Solaris time is other than January 1, 2001, contact a field engineer. In this case, do not execute the resetdateoffset(8) of setdate(8) command on the XSCF.- Case 3If the PPAR power is off, power on the PPAR. After that, check the Oracle Solaris time, and perform the above case 1 or case 2.
- If phenomenon 2 occurs: - Case 1If the Oracle Solaris time has returned to January 1, 2001, it is necessary to initialize the time difference between the XSCF time and Hypervisor on all of the PPARs. Stop all the PPARs, and execute the resetdateoffset -a command to clear the time difference.- Case 2If the Oracle Solaris time is other than January 1, 2001, contact a field engineer. In this case, do not execute the resetdateoffset(8) of setdate(8) command on the XSCF.- Case 3If the PPAR power is off, power on the PPAR. After that, check the Oracle Solaris time, and perform the above case 1 or case 2.
- If phenomenon 3 occurs: If phenomenon 1 or 2 also occurs, perform its [How to restore] action first.Set the Oracle Solaris time again.
< Previous Page | Next Page >