Skip to main content

Problems Resolved in XCP 2070


Problems Resolved in XCP 2070
The following table lists the problems resolved in XCP 2070.
Table 3-43  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 -a
PPAR-ID       Domain Date Offset
00            400000100 sec
01            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 -a
PPAR-ID       Domain Date Offset
00            -7205 sec
01            -7205 sec
02            -7205 sec
03            -7205 sec
04            -7205 sec
05            -7205 sec
06            -7205 sec
07            -7205 sec
08            -7205 sec
09            -7205 sec
10            -7205 sec
11            -7205 sec
12            -7205 sec
13            -7205 sec
14            -7205 sec
15            -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)
  1. 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:
1) Remove (Delete) the BB#x from a system.
2) Turn off the breaker of the BB#x.
3) After the exchanged device is connected with the system, turn on
   the breaker of the BB#x.
4) Please select[f:finish] :
  1. 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:
1) After the added device is connected with the system, please turn on
   the breaker of the BB#x.
2) Please select[f:finish] :

  1. 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.
XCP update has been completed (XCP version=xxxx:last version=yyyy)
Restoration After the "SCF Diagnosis initialize RTC" Error (RTIF2-131108-001)
[How to restore]
  1. If phenomenon 1 occurs:
    - Case 1

    If 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 2

    If 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 3

    If 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.
  2. If phenomenon 2 occurs:
    - Case 1

    If 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 2

    If 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 3

    If 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.
  3. If phenomenon 3 occurs:
    If phenomenon 1 or 2 also occurs, perform its [How to restore] action first.

    Set the Oracle Solaris time again.