Problems That Might Occur With XCP 2430 and Workarounds
Problems That Might Occur With XCP 2430 and Workarounds
The following table lists the problems that might occur with XCP 2430 and workarounds for them.
| RTI No. | RTIF2-170424-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose that the PCIe root complex connecting the PCI card is dynamically added to a logical domain with the ldm add-io command. In this case, there may be PCIe lane degradation on the PCI card. To check whether there is lane degradation, execute the prtdiag command of Oracle Solaris and check "Cur Speed/Width." |
| Workaround | There is no effective workaround. [How to restore] Restart the logical domain connected to this PCI card. |
| RTI No. | RTIF2-170405-001 |
| Model | SPARC M10-4S |
| Description | After completing the master XSCF switchover and executing the rebootxscf -a command or the setdate command to reboot all XSCFs, hardware errors may not be detectable. |
| Workaround | After the master XSCF switchover has completed, wait about 20 minutes and then execute the rebootxscf command or the setdate command. [How to restore] Reboot all the XSCFs by executing the rebootxscf -a command. |
| RTI No. | RTIF2-170405-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the poweroff -f command is executed while the physical partition (PPAR) is restarting, the next execution of the poweron command may cause an error that does not allow the PPAR to be powered on. [Example] The PPAR cannot be powered on. XSCF> poweron -p 0 PPAR-IDs to power on :00 Continue? [y|n] :y 00 : Not powering on : An internal error has occurred. Please contact your system administrator. |
| Workaround | Before executing the poweroff -f command, use the showpparprogress command to check the status of the target PPAR. If "PPAR reset" is displayed at this point, it means that the target PPAR is restarting. The PPAR restart is completed by the time that "The sequence of power control is completed." appears. Until this message appears, do not execute the poweroff -f command. If "This PPAR is powered on." or "This PPAR is powered off." appears, the PPAR has not been restarted. [Example] The PPAR restart has completed. XSCF> showpparprogress -p 0 PPAR reset PPAR#0 [ 1/13] : CPU Start PPAR#0 [13/13] The sequence of power control is completed. XSCF> [How to restore] Turn off the input power to the system, wait 30 seconds, and then turn it on again. (AC OFF/ON) |
| RTI No. | RTIF2-170405-005 |
| Model | SPARC M10-4S |
| Description | If you execute a command listed in [Command list] during XSCF master/standby switching, the following problems occur. - The XSCF that executes the command stops due to "BOARD ERROR." - Moreover, you cannot power on the physical partition containing the PSB (BB) of the stopped XSCF. You can confirm that the XSCF master/standby switching is completed by executing the showhardconf command to check that [Status] of XBBOX or BB is "Normal." [Command list] restoreconfig(8) rebootxscf(8) flashupdate(8) setdate(8) |
| Workaround | Do not execute any of the commands listed in [Command list] above during XSCF master/standby switching. [How to restore] Recover the system by performing the following procedure. 1. Shut down Oracle Solaris on all logical domains. 2. Execute the poweroff -f command to forcibly power off all PPARs. 3. Turn off (AC OFF) the input power to every SPARC M10. 4. Turn on (AC ON) the input power to every SPARC M10. |
| RTI No. | RTIF2-170405-007 |
| Model | SPARC M10-4S |
| Description | If the "SCF process down detected" error occurs on the standby XSCF while the XCP firmware is being updated, the "SCF panic detected" error may occur on the master XSCF. |
| Workaround | There is no effective workaround. After the reboot of every XSCF has completed, execute the flashupdate command with the -f option specified to update the XCP firmware again. |
| RTI No. | RTIF2-170405-008 |
| Model | SPARC M10-4S |
| Description | If a low-voltage problem in the XSCF unit occurs on the master XSCF, automatic master/standby switching may not occur. |
| Workaround | There is no effective workaround. If the master XSCF does not respond, execute the switchscf command with the -f option specified from the standby XSCF to forcibly switch the master/standby XSCF. [Example] XSCF> switchscf -t Master -f The XSCF unit switch between the Master and Standby states. Continue? [y|n]:y After the master/standby switching, replace the non-responsive XSCF unit. |
| RTI No. | RTIF2-170405-009 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When executed while a POST diagnosis is in progress on a PPAR consisting of one system board (PSB), the console command may not display the console screen. |
| Workaround | Execute the console command before the PPAR starts or after the POST diagnosis is completed. [How to restore] For a building block configuration, restart the PPAR (power), switch the master/standby XSCF, or reboot the master XSCF. For the SPARC M10-1, the SPARC M10-4, or the 1BB configuration with the SPARC M10-4S, power off the PPAR and then power it on again. |
| RTI No. | RTIF2-170405-010 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Normally, the occurrence of a memory configuration error is supposed to degrade all memory under the CPU. However, some memory has not been degraded. Powering on the PPAR at this time may register the non-degraded memory in an error log. [Example] The MEM#02B memory has been unmounted but the MEM#xxA memory is not degraded. XSCF> showstatus BB#00 Status:Normal; CMUL Status:Normal; * MEM#00B Status:Deconfigured; * MEM#01B Status:Deconfigured; * MEM#03B Status:Deconfigured; [Example] Example of an error log XSCF> showlogs error Date: Nov 22 10:57:37 JST 2016 Code: 40002000-004b830134110000ff-020014210000000000000000 Status: Warning Occurred: Nov 22 10:57:37.190 JST 2016 FRU: /BB#0/CMUL/MEM#03A,/BB#0/CMUL Msg: Failed to find write cycle adjustment value Diagnostic Code: 00000300 00000000 0000 00000001 00000000 0000 |
| Workaround | Before powering on the PPAR, execute the showhardconf command and confirm that the memory is correctly mounted in accordance with memory mounting rules. Remount any memory that is not correctly mounted. [How to restore] Remount the memory correctly in accordance with memory mounting rules. With the mode switch in the Service mode position on the operation panel, turn on (AC ON) the input power to cancel the degradation of the memory registered with an error. Execute the showstatus command to confirm that the memory is not degraded. |
| RTI No. | RTIF2-161116-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If available CPU resources in a physical partition (PPAR) have not been assigned when a CPU Activation Interim Permit expires, powering on the PPAR causes the PPAR to be reset repeatedly without power-on processing being suppressed. At this time, the following event log is registered repeatedly. SCF:PPAR-ID x: Reset SCF:SP-Config falling back to factory-default (PPARID 0 factor:0x1010000) SCF:PPAR-ID x: Reset released |
| Workaround | After a CPU Activation Interim Permit expires, execute the setinterimpermit disable command to disable the CPU Activation Interim Permit. To power on a PPAR, assign available CPU core resources in the PPAR. [How to restore] Perform the following procedure. 1. Execute the poweroff -f command to forcibly power off the PPAR that is being reset repeatedly. 2. Execute the poweroff command (without -f) to power off all PPARs other than that described above. 3. Turn off/on (AC OFF/ON) the input power to every SPARC M10. 4. Execute the setinterimpermit disable command to disable the CPU Activation Interim Permit. |
| RTI No. | RTIF2-150730-001 |
| Model | SPARC M10-4S |
| Description | The message "Cannot communicate with BB#xx. Please check BB#xx's state." is output when the setprivileges(8) command is executed. [Example] XSCF> setprivileges jsmith fieldeng platadm useradm auditadm Cannot communicate with BB#01. Please check BB#01's state. XSCF> |
| Workaround | There is no effective workaround. User privileges are normally set. This message does not affect system operation. |
| RTI No. | RTIF2-150728-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the ioxadm(8) command is executed for the first firmware update of the PCI expansion unit after shipment, the event log will display an incorrect firmware version: "last version=0000". [Example of the event log] May 28 11:27:40 Event: SCF:LINKCARD update is started (LINKCARD=0, bank=1, PCIBOX version=1200: last version=0000) |
| Workaround | There is no effective workaround. Ignore this version in the event log. This problem does not affect system operation. |
| RTI No. | RTIF2-150629-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When using the Africa/Casablanca time zone, executing showtimezone -c dst-m standard does not display daylight saving time but outputs the following message: An internal error has occurred. Please contact your system administrator. This is a problem with the command output only. Daylight saving time is set as follows twice a year. Starts March 29, 2015 and ends June 13, 2015 Starts July 18, 2015 and ends October 25, 2015 |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-150629-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The log of "Event: SCF:XCP update has been completed" may be registered at the XCP firmware update time, indicating a successful firmware update. However, the firmware may not actually have been updated in some SPARC M10 system chassis or crossbar boxes. |
| Workaround | There is no effective workaround. In either of the following cases about the registered logs at the XCP firmware update time (logs from "SCF:XCP update is started (XCP version=xxxx:last version=yyyy)" to "SCF:XCP update has been completed (XCP version=xxxx:last version=yyyy)"), update the XCP firmware again. - "SCF:XSCF update is started (BBID=x, bank=y)" is not logged twice for each SPARC M10 chassis. - Either of the following logs is registered, indicating a connected SPARC M10 system chassis has an error. [Example 1] XSCF> showlogs monitor -r Alarm: /XBBOX#81/XSCFU:SCF:XSCF hang-up is detected [Example 2] XSCF> showlogs monitor -r Notice: /FIRMWARE,/BB#0/CMUL:SCF:SCF panic detected |
| RTI No. | RTIF2-150226-002 |
| Model | SPARC M10-4S |
| Description | CHECK LED of the old master XSCF blinks during the master/standby switchover of XSCFs. |
| Workaround | There is no effective workaround. Ignore the blinking CHECK LED of the old master XSCF during the master/standby switchover of XSCFs. |
| RTI No. | RTIF2-150218-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose you execute any of the following on a system with a PCI expansion unit connected when the power to the physical partition is on. In such a case, an SNMP Trap related to the addition of the PCI expansion unit or the link card is sent by mistake. - Reset the XSCF - Switch the master/standby XSCF - Change the SNMP agent from the disabled state to the enabled state - Set the SNMP agent management information when the SNMP agent is enabled In such a case, the following SNMP Traps are sent: - PCI expansion unit addition scfPciBoxEvent scfTrapEventType=add(10) - Link card addition scfComponentEvent scfTrapEventType=add(10) Similarly, the following SNMP Trap on the PCIe card addition is sent by mistake in a system with a PCIe card connected. scfComponentEvent scfTrapEventType=add(10) |
| Workaround | There is no effective workaround. This incorrectly sent SNMP Trap does not affect the behavior of the PCI expansion unit or the PCIe card. |
| RTI No. | RTIF2-141204-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the guest domain has been kept active for a long time, powering off and on the physical partition (PPAR) may cause the guest domain time to shift. This phenomenon occurs under the following conditions. - A guest domain is configured (*1), and - a long period of time passes after the ldm add-spconfig command is executed from Oracle VM Server for SPARC (*2), and - a physical partition is powered on or reset *1 Time deviation does not occur on the control domain. *2 Time deviation comes to about 20 seconds per month. |
| Workaround | Immediately before powering off a physical partition or resetting it, execute the ldm addspconfig from Oracle VM Server for SPARC, and store the latest guest domain configuration information on the XSCF. [How to restore] If the time of a guest domain has shifted, start up Oracle Solaris in single user mode, and synchronize the time. [Example] Setting of 18:30:00 on June 27, 2014 # date 0627183014.00 # date 0627183014.00 |
| RTI No. | RTIF2-140804-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Although the showstatus(8) command is executed when there are no faulty components, the message "No failures found in System Initialization.", indicating that there are no faulty components, does not appear. [Example] XSCF> showstatus XSCF> |
| Workaround | There is no effective workaround. If no message appears, there are no faulty components. You can continue system operation. |
| RTI No. | RTIF2-140616-001 |
| Model | SPARC M10-1 |
| Description | The showhardconf(8) command executed on a SPARC M10-1 does not display [Type] for the power supply unit (PSU). Either "Type: A" or "Type: B" should be displayed as the PSU type. The meaning of each value of "Type" is as follows: - Type: A: PSU for SPARC64 X - Type: B: PSU for SPARC64 X+ |
| Workaround | When you execute the showhardconf(8) command, it displays "FRU-Part-Number:CAXXXXXXXXX-X/xxxxxxx ;" as part of the PSU information. You can determine the PSU type by checking the value of "CAXXXXX-XXXX-X" in this information. - If the value of CAXXXXX-XXXX-X is "CA01022-0750-M" Type: A: PSU for SPARC64 X - If the value of CAXXXXX-XXXX-X is "CA01022-0751-M" Type: B: PSU for SPARC64 X+ If multiple PSU types are mounted mixed, you can determine the PSU type by checking the value of "XXXXXX" in the error log "Code:80000000-XXXXXX0000ff0000ffxxxxxxxxxx00000000000000" output by the showlogs error command. - If the value of XXXXXX is "002400" Type: A: PSU for SPARC64 X - If the value of XXXXXX is "002401" Type: B: PSU for SPARC64 X+ |
| RTI No. | RTIF2-140616-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the procedure below is executed, the error message "An internal error has occurred. Please contact your system administrator." is displayed at execution of the prtfru(8) command and the command abnormally terminates. 1. Turn on the input power and then execute the rebootxscf(8) or switchscf(8) command to start or reset the XSCF. 2. Execute the snapshot(8) command. 3. Execute the prtfru(8) command. |
| Workaround | After starting or resetting the XSCF, execute the prtfru(8) command before executing the snapshot(8) command. [How to restore] Execute the rebootxscf -a command to reset all XSCFs. |
| RTI No. | RTIF2-140606-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose that a cluster system is built to fulfill the following condition: it is composed of multiple SPARC M10 system chassis, each of which includes 10 or more guest domains (10 or more cluster nodes) running in 1 physical partition (PPAR). Moreover, PRIMECLUSTER software is installed on each of these guest domains. Alternatively, the cluster system is composed of multiple PPARs within the SPARC M10 system chassis. If you execute the poweroff -f command on one PPAR to forcibly turn off the power to that PPAR, the XSCF may slow down, panic, and then reset. |
| Workaround | Confirm that less than 10 cluster nodes are included in one PPAR that exists on an instance of the SPARC M10-1, SPARC M10-4, or SPARC M10-4S. [How to restore] The system will be available as is because processing of the poweroff(8) command continues after an XSCF panic and reset. |
| RTI No. | RTIF2-140606-004 |
| Model | SPARC M10-4S |
| Description | Suppose that you execute the addboard(8) and reset por commands to add a system board (PSB) to a physical partition (PPAR) that fulfills both of the conditions below. You may see an error message "No analytical target" repeatedly. Also, Oracle Solaris running on this PPAR may hang. - The SPARC M10-4S (including a crossbar box) has a building-block configuration. - Power is supplied only to a PPAR made up of one PSB. |
| Workaround | To add a PSB to a PPAR that fulfills both of the conditions above, use one of the following methods: - Turn off the power to the PPAR, and then execute the addboard(8) command to add a PSB. - After executing the addboard(8) command to add a PSB, turn off the power to the PPAR, turn it on again, and then rebuild the PPAR. - Using the DR function, execute the addboard(8) command to add a PSB. [How to restore] - If the error message "No analytical target" is not displayed Execute the poweroff(8) command to turn off the power to the PPAR, and then execute the poweron(8) command to turn on the power to the PPAR. - If the error message "No analytical target" is displayed Execute the poweroff -f command to forcibly turn off the power to the PPAR and then execute the poweron(8) command to turn on the power to the PPAR. |
| RTI No. | RTIF2-140606-008 |
| Model | SPARC M10-4S |
| Description | Suppose you attempt to use dynamic reconfiguration of physical partitions (PPARs) to add a system board (PSB) with the addboard -c configure command or disconnect a PSB with the deleteboard -c unassign or deleteboard -c disconnect command. If your attempt satisfies any of the following conditions, switching between master and standby XSCFs occurs. If the rebooting XSCF in the following conditions is the standby XSCF, it becomes the master XSCF after the switching. The previous master XSCF is reset and deactivated. [Condition] - In the case of addboard - The XSCF for the PSB to be added is rebooting. - The PSB is to be deleted from a PPAR, and the XSCF for any of the PSBs making up the PPAR is rebooting. - In the case of deleteboard - The XSCF for one of the PSBs making up the PPAR from which the PSB is to be deleted is rebooting. |
| Workaround | If there is a standby XSCF that fulfills one of the conditions above, execute the addboard(8) or deleteboard(8) command after the standby XSCF has rebooted. Check whether the XSCF has rebooted, by executing the showhardconf(8) command to confirm that the [Status] of the SPARC M10-4S chassis (BB#xx) that includes the XSCF is "Normal". [Example] - The XSCF at BB#02 is running. XSCF> showhardconf SPARC M10-4S; --- Omitted --- BB#02 Status:Normal; Role:Slave; Ver:2220h; Serial:1234567890; - The XSCF at BB#02 is rebooting. XSCF> showhardconf SPARC M10-4S; --- Omitted --- BB#02 Status:Cannot communicate; [How to restore] Even if switching between master and standby XSCFs occurs, you can continue using the system because the addboard(8) or deleteboard(8) command has been executed correctly. If the previous master XSCF has stopped, execute the following procedure: 1. Execute the poweroff -a command to turn off the power to all PPARs. 2. Turn off the input power to the SPARC M10-4S chassis configured on the master and standby XSCFs, and then turn it on again. 3. Log in to the master XSCF and execute the showhardconf(8) command to confirm that the [Status] of the SPARC M10-4S chassis for the standby XSCF is "Normal". |
| RTI No. | RTIF2-140605-001 |
| Model | SPARC M10-4S |
| Description | Suppose the following scenario. You turn on the power to a physical partition (PPAR) that consists of multiple SPARC M10-4S chassis. The PPAR/domain enters a state that is between self-diagnosis test (POST) completion (Initialization Complete) and OpenBoot PROM start completion (OpenBoot Running). If the XSCF in a SPARC M10-4S in the PPAR resets in this state, you may be unable to switch to the control domain console. You can confirm that this event has occurred by executing the showlogs event command and confirming that an event log for console path switching was registered during the time between POST diagnosis completion and OpenBoot PROM start completion. [Example] Event log message issued when PPAR-ID is 0 POST Diag complete from PPAR (PPAR ID 0) --- Omitted --- PPAR ID 0: Console path is switched --- Omitted --- PPARID 0 GID 00000000 state change (OpenBoot Running) |
| Workaround | There is no effective workaround. [How to restore] Perform one of the following operations: - Execute the rebootxscf -a command. - From XSCF Web, reset all XSCFs. - Turn off the power to the PPAR, and then turn it on again. |
| RTI No. | RTIF2-140605-002 |
| Model | SPARC M10-4S |
| Description | Suppose that all but one of the system boards (PSBs) that make up a physical partition (PPAR) are faulty. If you attempt to use the DR function to disconnect the normal PSB by executing the deleteboard(8) command, this command times out and terminates abnormally. In addition, if you execute the deleteboard(8) command using the DR function to disconnect another PSB in the same PPAR, the command always times out. Furthermore, you can no longer connect to the control domain console by executing the console(8) command. [Example] deleteboard(8) command timeout XSCF> deleteboard -c disconnect 00-0 PSB#00-0 will be unconfigured from PPAR immediately. Continue?[y|n] :y All domains are temporarily suspended, proceed?[y|n] :y Start unconfigure preparation of PSB. [1200sec] 0..... 30..... 60..... 90.....120.....150.....180.....210.....240.....\ 270.....300.....330.....360.....390.....420.....450.....480.....510.....\ 540.....570.....600.....630.....660.....690.....720.....750.....780.....\ 810.....840.....870.....900.....930.....960.....990.....1020.....1050.....- 1080.....1110.....1140.....1170.....end Timeout detected during unconfiguration of PSB#00-0. XSCF> |
| Workaround | If all but one of the PSBs are faulty, first turn off the power to the PPAR, and then execute the deleteboard(8) command to disconnect the PSB. [How to restore] Perform the following procedure. 1. Execute the rebootxscf -a command to reset the XSCF. 2. Check the error logs and messages to identify the cause of the error. 3. Eliminate the cause of the error. 4. Perform the operation described in "6.3.1 Example of Operations for Deleting a System Board Assignment" or the operation described in "6.3.3 Example of Operations for Reserving a System Board Unassignment" in the Fujitsu SPARC M12 and Fujitsu M10/SPARC M10 Domain Configuration Guide. |
| RTI No. | RTIF2-140605-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the OS panics, a large volume of panic messages may be sent to the XSCF. In this case, the XSCF cannot handle the large volume of panic messages. As a result, the codd process fails and OS-panic error logs are registered in large quantities as shown below. [Example] OS panic and process failure error logs XSCF> showlogs error -v Date: Dec 20 14:44:26 JST 2013 Code: 40000000-00ffff0000ff0000ff-01b900060000000000000000 Status: Warning Occurred: Dec 20 14:44:26.513 JST 2013 FRU: /UNSPECIFIED Msg: XSCF command: System status change (OS panic) (PPARID#00, path: 00) Diagnostic Code: 00000000 00000000 0000 00000000 00000000 0000 00000000 00000000 0000 00000000 00000000 00000000 00000000 00000000 00000000 0000 Date: Dec 20 15:00:01 JST 2013 Code: 20000000-00fcff00b0000000ff-010400010000000000000000 Status: Notice Occurred: Dec 20 14:59:56.838 JST 2013 FRU: /FIRMWARE,/XBBOX#81/XSCFU Msg: SCF process down detected Diagnostic Code: 00000000 00000000 0000 51000000 00000000 0000 00000000 00000000 0000 636f6464 2e323537 382e627a 32000000 00000000 00000000 0000 You can confirm this codd condition by checking for "636f6464" in the first four bytes on the fourth line of [Diagnostic Code:]. |
| Workaround | There is no effective workaround. [How to restore] The system is restored when the XSCF is reset by codd process failure. |
| RTI No. | RTIF2-140507-003 |
| Model | SPARC M10-4S |
| Description | After adding or removing a system board with the dynamic reconfiguration of physical partitions (PPAR), if the PPAR is powered off, the output of the showpparprogress(8) command mistakenly shows the status of the procedure of powering on the system. |
| Workaround | There is no effective workaround. [How to restore] After the "PPAR-ID x: Reset" message is output to the event log, re-execute the showpparprogress(8) command for the right display. |
| RTI No. | RTIF2-140507-005 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If a failure is detected in DC-DC converter (DDC), "Power subsystem failure" may be registered twice in the error log. |
| Workaround | There is no effective workaround. Ignore the second of these entries in the error log. Moreover, replace the faulty FRU as soon as possible. |
| RTI No. | RTIF2-140507-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When error logs (Critical ultrahigh temperature at XXX) at the time of component abnormalities due to high temperature (ultrahigh temperature level) are registered and the system is forcibly stopped, if the showlogs power command is executed, the "Cause" column to the power log may show "-". |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140507-007 |
| Model | SPARC M10-4, SPARC M10-4S |
| Description | After a DC-DC converter (DDC) fault has been detected, if the system is run continuously, without replacing the FRU that appears in the error logs, the following error is mistakenly detected every time the input power is turned off. Msg: Power-off failure |
| Workaround | Replace the faulty FRU. Moreover, as this error message has no effect on the functioning of the system, ignore it. |
| RTI No. | RTIF2-140507-009 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Even though a rotation abnormality has been simultaneously detected on both of the fans in one fan unit, only an error of one fan is recorded in the error log, so the system is not shut down. As a result, the temperature of components, like CPUs, may rise. |
| Workaround | There is no effective workaround. [How to restore] If the system is not shut down when fan rotation abnormality is detected, if any of the following symptom is confirmed in the two fans which comprises the faulty fan unit, change the following fan unit as soon as possible: - The showenvironment fan command shows that the number of rotations has decreased. - A visual check reveals that both fans stopped at the same time. |
| RTI No. | RTIF2-140507-014 |
| Model | SPARC M10-4S |
| Description | When the replacefru(8), addfru(8), or rebootxscf(8) command is executed, the "XSCF hang-up is detected" error may be detected by the slave XSCF. |
| Workaround | There is no effective workaround. Ignore this error log message since the command in question ended normally and thus has no effect on the system. |
| RTI No. | RTIF2-140507-016 |
| Model | SPARC M10-4S |
| Description | After configuring the XSCF network with the setnetwork(8) command and applying the configuration by the applynetwork(8) command, if you execute the shownetwork(8) command without executing the rebootxscf(8) command, the displayed IP address may not match the IP address that is being used on the present system. |
| Workaround | After executing the applynetwork(8) command to apply network configurations of the XSCF, execute the rebootxscf(8) command to reset the XSCF. |
| RTI No. | RTIF2-140507-021 |
| Model | SPARC M10-4S |
| Description | In the middle of a diagnosis performed by the diagxbu(8) command with the -p and -b options specified, if a failure occurs in the physical partition specified by the -p option, the diagxbu(8) command may terminate abnormally, and power-off of the SPARC M10 chassis specified by the -b option may fail. |
| Workaround | There is no effective workaround. [How to restore] Perform the following procedure. 1. Turn off the input power (AC OFF) of the SPARC M10 chassis specified by the -b option of the diagxbu(8) command. 2. Select the SPARC M10 chassis by the "-b" option of the replacefru(8) command. 3. When the message for the replacement of the SPARC M10 chassis is output in the maintenance menu, turn on the input power (AC ON) of the SPARC M10 chassis without replacing it. |
| RTI No. | RTIF2-140507-022 |
| Model | SPARC M10-4S |
| Description | When the crossbar cable of the crossbar unit (XBU) in the SPARC M10-4S has a bad electrical contact, the crossbar cable components are depicted with a number of "#"s by the showhardconf(8) command. [Example] When the crossbar cable is loose: + FRU-Part-Number:################; Ver:####h; + Type:#######; Length: #; |
| Workaround | There is no effective workaround. [How to restore] Perform the following procedure. 1. Power off the physical partition (PPAR) by the poweroff(8) command. 2. Check the physical state of the crossbar cable (loose connection, disconnection, etc.) whose component information is depicted by a number of "#"s. 3. Execute the poweron(8) command to power on the PPAR. 4. Check the component information of the target crossbar cable with the showhardconf(8) command. [Example] When the crossbar cable is properly connected: + FRU-Part-Number:2123628-2 ; Ver:3920h; + Type:Optic; Length: 2; |
| RTI No. | RTIF2-140410-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If, during execution of the restoreconfig(8) command, you power on or off the physical partition (PPAR) or execute diagnosis of the system board, the operations in progress are interrupted. |
| Workaround | During execution of the restoreconfig(8) command, do not power on or off the physical partition (PPAR) or execute diagnosis of the system board. [How to restore] - If the PPAR power on process is interrupted Forcibly power off the PPAR by executing the poweroff -f command. - If the PPAR power off process or system board diagnosis is interrupted Turn off the input power to all SPARC M10 system chassis or crossbar box chassis, and then turn it on again (AC OFF/ON). |
| RTI No. | RTIF2-140410-003 |
| Model | SPARC M10-4S |
| Description | With the system input power turned off, if the CPU memory unit lower (CMUL) is replaced or the SPARC M10-4S is added without using the maintenance menu, the following error log may be registered when automatic synchronization of XCP firmware versions is enabled. Alarm: :SCF:Gaps between XBBOX-ID Or Information: :SCF:Gaps between BB-ID |
| Workaround | There is no effective workaround. Ignore this error log entry. |
| RTI No. | RTIF2-140410-008 |
| Model | SPARC M10-4S |
| Description | After the input power is turned on with the XSCF DUAL control cable disconnected or faulty, data between the master and standby XSCFs is not synchronized even if the XSCF DUAL control cable is restored. System operation can continue. However, after master/standby XSCF switching, normal system operation is not guaranteed. This is because information in the old master XSCF is not reflected in the new XSCF. You can check, with the following error log messages, whether the XSCF DUAL control cable is disconnected or faulty: - XSCF DUAL control cable is disconnected Msg: BB control cable detected unexpected - XSCF DUAL control cable is faulty Msg: Cannot communicate with the other XSCF |
| Workaround | Before turning on the input power, confirm that the XSCF DUAL control cable is correctly inserted. Also, use the showlogs error command to confirm that the error logs shown in [Description] are not registered. [How to restore] If the XSCF DUAL control cable is disconnected, make sure that it is properly connected. Then, execute the rebootxscf -a command to reboot all XSCFs. If the XSCF DUAL control cable is faulty, replace the cable. |
| RTI No. | RTIF2-140410-009 |
| Model | SPARC M10-4S |
| Description | If the input power to the standby or slave chassis is turned off, a "Board control error (MBC link error)" error log may be registered. |
| Workaround | There is no effective workaround. Ignore this error log entry. |
| RTI No. | RTIF2-140409-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | An error may be detected in the Realtime Clock (RTC) built into the SPARC M10 system and XSCF may not start. |
| Workaround | There is no effective workaround. [How to restore] Turn off the input power to the system and then turn it on again (AC OFF/ON). |
| RTI No. | RTIF2-140407-005 |
| Model | SPARC M10-4, SPARC M10-4S |
| Description | Suppose that the CPU memory unit lower (CMUL) or CPU memory unit upper (CMUU) has a faulty DC-DC converter (DDC) and the system operates continuously without the CMUL/CMUU being replaced. In this case, CPU-related failures may not be detected, even if an error occurs on a CPU mounted in the CMUL/CMUU with the faulty DDC, and the physical partition (PPAR) may hang. For a DDC failure, check whether any of the following messages are registered in the error log. Msg: Critical low voltage error Or Msg: Critical high voltage error Or Msg: Power subsystem failure |
| Workaround | Immediately replace the CMUU or CMUL where the DDC failure has occurred. |
| RTI No. | RTIF2-140407-006 |
| Model | SPARC M10-4S |
| Description | For a SPARC M10-4S chassis with the XSCF stopped, or with the input power off (AC OFF), even if you execute the initbb -f command to forcibly disconnect the chassis from the system, the chassis remains assigned to the physical partition (PPAR). To check this phenomenon, execute the showboards(8) command to check whether Assignment of the target SPARC M10-4S chassis (PSB) remains "Assigned". |
| Workaround | There is no effective workaround. [How to restore] Perform the following on the disconnected SPARC M10-4S chassis. 1. Execute the replacefru(8) command to replace the chassis. 2. Power on (AC ON) the replacement chassis. - If the READY LED of the XSCF or XSCF unit is lit a. Complete replacefru(8) command execution by following the maintenance menu. b. Execute the initbb(8) command to disconnect the chassis from the system. - If the READY LED of the XSCF or XSCF unit is not lit Remove the chassis and replace the XSCF unit or CPU memory unit lower (CMUL) where a failure is suspected. |
| RTI No. | RTIF2-140407-008 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the poweroff(8) command is executed and the master chassis XSCF is reset during the time that it takes for a prompt to be returned, the following power on/power off operation cannot be executed. |
| Workaround | There is no effective workaround. If this phenomenon occurs, turn off the input power to all chassis and then turn it on again. |
| RTI No. | RTIF2-140304-001 |
| Model | SPARC M10-4S |
| Description | When performing AC OFF/ON, in some very rare cases. the "SCF process down detected" error message is registered and XSCF fails to start. |
| Workaround | There is no effective workaround. If this symptom has occurred, contact a field engineer. |
| RTI No. | RTIF2-140304-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The "SCF process down detected" error log may be registered when the flashupdate(8) command is running. |
| Workaround | There is no effective workaround. [When restoration is not required] If both of the following conditions are met, there is no need for restoration. It may be assumed that the firmware update has completed properly. - The showlogs error -rv command reveals that the following diagnostic message along with the "Msg: SCF process down detected" error message had been registered when the flashupdate(8) command was running. [Example] Diagnostic Code: 00000000 00000000 0000 00000000 00000000 0000 00000000 00000000 0000 666c6173 68757064 6174652e xxxxxxxx 00000000 00000000 0000 where xxxxxxxx is indefinite - The showlogs event command displays the "XCP update has been completed" event log. [How to restore] Re-execute the flashupdate(8) command. |
| RTI No. | RTIF2-140304-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | With SNMPv3, if the trap host name registered by the setsnmp(8) command contains a colon (:), it does not show up properly with the showsnmp(8) command. [Example] In case the trap host name is "test:example.com", the host name is shown as "test" and port number is shown as "0". |
| Workaround | With SNMPv3, do not execute the setsnmp(8) command to register a trap host name that contains a colon (:). If such a trap host name has already been registered, use the following command to remove the trap host name: setsnmp remv3traphost -u 'user_name' -p 'port_number' 'trap_host_name' In such a case, be sure to specify a port number. If the port number is not specified when removing a trap host name that includes a colon(:), the "Entry does not exist" message is displayed and the trap host name is not removed. The port number specified at the time of removal should be the one specified at the time of registration, and not the wrong one displayed by the showsnmp(8) command. |
| RTI No. | RTIF2-140304-004 |
| Model | SPARC M10-4S |
| Description | In the case of a SPARC M10-4S that is attached to a crossbar box, if an XSCF failure occurs on a portion of the chassis when the physical partition (PPAR) is in the powered on state, the following symptom may occur. - Symptom 1 When the poweroff(8) command is executed, the power on the PPAR is turned off, but the command prompt does not respond for about 20 minutes. - Symptom 2 When the PPAR is powered on, the "XB-XB interface fatal error" error occurs, the power-on process is repeated, and it does not end normally. |
| Workaround | If an XSCF failure has occurred, replace the CPU memory unit lower (CMUL) or the XSCF unit. [How to restore] - Case of symptom 1 After about 20 minutes, the poweroff(8) command ends properly and the prompt comes back. - Case of symptom 2 Forcibly power off the PPAR by executing the poweroff -f command. |
| RTI No. | RTIF2-140304-005 |
| Model | SPARC M10-4S |
| Description | On a physical partition (PPAR) that is composed of several SPARC M10-4S chassis (system boards), after a system board has been degraded due to failure, if you execute the setpciboxdio(8) command to disable/enable the direct I/O feature of the PCI cards mounted in the PCI expansion unit attached to the degraded chassis without powering off the PPAR first, the following message is output and the command fails: This operation cannot be done because the PPAR including a PSB of the target BB is powered on. This symptom occurs when a system board is in a state like the following, which is shown by either the showhardconf(8) or showboards(8) command. [Example] When PSB#01-0 (BB#01) has been degraded. XSCF> showhardconf: * BB#01 Status:Deconfigured; : XSCF> showboards -a PSB PPAR-ID(LSB) Assignment Pwr Conn Conf Test Fault ---- ------------ ----------- ---- ---- ---- ------- -------- 01-0 00(01) Assigned n n n Passed Faulted |
| Workaround | Change the configuration of the direct I/O feature with the setpciboxdio(8) command only after removing the degraded system board from the physical partition with the deleteboard(8) command. [Example] XSCF> deleteboard -c unassign 01-0After changing the configuration of the direct I/O feature, assign the system board to the PPAR with the addboard(8) command, and then incorporate the system board into the PPAR by following the maintenance procedure. [Example] XSCF> addboard -c assign -p 0 01-0Meanwhile, from XCP 2210 onwards, this problem can be solved by performing maintenance on the degraded chassis by the replacefru(8) command. In such a case, the above procedure is unnecessary. |
| RTI No. | RTIF2-140304-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the power supply unit (PSU) fails due to any of the following errors, and after active replacement or hot replacement of the PSU by the replacefru(8) command, if any of the following errors re-occur on the PSU of the same chassis, no error log is registered. - PSU shortage (power off started) - PSU shortage - Wrong PSU is installed |
| Workaround | Execute the replacefru(8) command to perform cold replacement if a PSU is replaced for the first time after any of the error logs shown in [Description] is registered. In such a case, do not perform active replacement or hot replacement. |
| RTI No. | RTIF2-140304-007 |
| Model | SPARC M10-4S |
| Description | When replacing power supply units (PSUs) with the replacefru(8) command, if the [f] key in the menu of the replacefru(8) command is pressed within 30 seconds after mounting the new PSU, any problem in the new PSU cannot be detected. |
| Workaround | See "Workaround for RTIF2-140304-007." |
| RTI No. | RTIF2-140227-005 |
| Model | SPARC M10-4S |
| Description | At the time of cold replacement or cold addition of the CPU memory unit lower (CMUL) or a SPARC M10 chassis, if the following conditions are met, the "XCP firmware version synchronization failed" message may be registered in the event log, and maintenance or addition fails. - Two or more CMUL or SPARC M10 chassis are cold replaced or cold added at one time. - The XCP versions of replacement components do not match the version of the master XCP. |
| Workaround | When cold replacing or cold adding two or more CMUL or SPARC M10 chassis, use the replacefru(8) or addfru(8) command to perform the operations one by one. [How to restore] Execute any of the following procedures. - Procedure 1 1. Turn off the input power to the system and then turn it on again (AC OFF/ON). 2. Execute the flashupdate(8) command, specifying the XCP version. XSCF> flashupdate -c update -m xcp -s xxxx -f xxxx is the XCP version of the master XSCF. - Procedure 2 Execute the replacefru(8) command to perform a pseudo replacement of the CMUL or SPARC M10 chassis that failed to be cold replaced. |
| RTI No. | RTIF2-140227-009 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If XSCF login is performed with an XSCF user account whose privileges are managed by the LDAP server specified in the setldap(8) command, execution of commands in the XSCF shell or operations on XSCF Web may take a while. |
| Workaround | In the case of an LDAP server specified by the setldap(8) command, there is no effective workaround. Specify the LDAP server with the setldapssl(8) command. |
| RTI No. | RTIF2-140227-010 |
| Model | SPARC M10-4S |
| Description | The following improper error message is displayed when the addboard -c configure command is executed, specifying a non-existing system board (PSB): PPAR is currently unavailable for DR, because XBU status has failed. Or The current configuration does not support this operation. |
| Workaround | There is no effective workaround. Execute the addboard -c configure command, specifying existent PSBs. |
| RTI No. | RTIF2-140212-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The OID information of scfPsbInfo in the definition file of the XSCF extension MIB is not updated even when the system board (PSB) information is updated. |
| Workaround | Restart the snmp daemon by using any of the setsnmp(8), setsnmpusm(8), and setsnmpvacm(8) commands, or reset the XSCF. |
| RTI No. | RTIF2-140212-005 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In the OID information of scfComponentStatusEvent in the XSCF extended MIB definition file, the paths of suspected components may be reported as "unspecified" information in trap notifications. This symptom occurs when the OID "FaultEventCode" information is any of the following: 05018113 05018123 05018133 05018211 05018221 05018231 |
| Workaround | There is no effective workaround. Execute the showlogs error command to confirm the suspected location. |
| RTI No. | RTIF2-140212-007 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When an attempt is made to register a password containing 256 or more characters, in the password input prompt of either the setsnmp(8) or the setsnmpusm(8) command, only 255 characters are registered. |
| Workaround | When setting up a password equal to or longer than 256 letters, use the password option of either the setsnmp(8) or the setsnmpusm(8) command, instead of using the password input prompt. [How to restore] If a password equal to or longer than 256 characters has been registered using the password input prompt, remove the target user data with either the setsnmp remv3traphost or setsnmpusm delete command and then register the user again. |
| RTI No. | RTIF2-140212-011 |
| Model | SPARC M10-4S |
| Description | If the XSCF master/standby switchover occurs when the physical partition (PPAR) is running, in some very rare cases, a "process down" may occur on the XSCF and the XSCF may be reset. |
| Workaround | There is no effective workaround. The system can be operated continuously as it will be restored after being reset. |
| RTI No. | RTIF2-140212-014 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Even if the "CPU cache degraded (CPU #xx)" error is detected, the CHECK LED of the operation panel may not light up. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140212-016 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When resetting the XSCF, "the XSCF serial terminal may display the SNMP-related "snmpd[XXXXX] svrSP: error doAction ACTION_CONTROL_LED" error message. |
| Workaround | There is no effective workaround. Ignore this message. |
| RTI No. | RTIF2-140212-021 |
| Model | SPARC M10-4S |
| Description | If any of the physical partitions is reset due to some hardware failure, in the middle of the execution of the testsb(8) command, the testsb(8) command may terminate abnormally. The following is an example of such an error. [Example] XSCF> testsb PSB_NO Initial diagnosis is about to start, Continue?[y|n] :y SB power on sequence started. 0.....30.....end Initial diagnosis started. [7200sec] 0..... 30..... 60..... 90.....120.....150.....180.....210.....240..... 270.....300.....330.. Hardware error occurred by initial diagnosis. SB power off sequence started. [1200sec] 0..... 30..... 60..... 90.....120.....150.....180.....210.....240..... 270.....300.....330.....360.....390.....420.....450.....480.....510..... 540.....570.....600.....630.....660.....690.....720.....750.....780..... 810.....840.....870.....900.....930.....960.....990.....1020.....1050..... 1080.....1110.....1140.....1170.....1200end Failed to power off. Please check the FRU. An internal error has occurred. Please contact your system administrator. done. |
| Workaround | There is no effective workaround. [How to restore] After confirming the faulty hardware with the showlogs(8) command, perform maintenance on the hardware. After that, execute the testsb(8) command again. |
| RTI No. | RTIF2-140121-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the input power is turned off (AC OFF) while the XSCF is processing large amounts of data, only occasionally, the XSCF may not start up when the input power in turned on (AC ON) again. |
| Workaround | There is no effective workaround. Contact a field engineer if this problem occurs. |
| RTI No. | RTIF2-131213-002 |
| Model | SPARC M10-4S |
| Description | While in the process of adding or removing a system board (PSB) by using the addboard(8) or deleteboard(8) command of the DR feature, if another physical partition is rebooted due to a hardware failure or execution of the poweroff(8)/poweron(8)/reset(8) command on it, the executed addboard(8) or deleteboard(8) command may detect a timeout and terminate abnormally. |
| Workaround | Do not execute the poweroff(8)/poweron(8)/reset(8) command while the addboard(8) or deleteboard(8) command is being executed. There is no effective workaround if any hardware failure occurs while executing DR. [How to restore] Check the status of the system board (PSB) using the showboards(8) command. Execute the addboard(8) or deleteboard(8) command after that. |
| RTI No. | RTIF2-131213-003 |
| Model | SPARC M10-4S |
| Description | While executing the poweroff(8)/poweron(8)/reset(8) command on a physical partition, if the addboard(8) or the deleteboard(8) command of the DR feature is executed on another physical partition to add or remove a system board (PSB), the addboard(8) or deleteboard(8) command may detect timeout and terminate abnormally. |
| Workaround | Do not execute the addboard(8) or deleteboard(8) command while the poweroff(8)/poweron(8)/reset(8) command is being executed elsewhere. There is no effective workaround if DR is executed while also executing power supply operations on another physical partition. [How to restore] Perform the following procedure. 1. Execute the showboards(8) command. 2. Check the status of /Pwr/Conn/Conf/Test of the system board (PSB) to confirm the end of power operations. - Power-on/Reset completed The Pwr/Conn/Conf/Test status is "y y y passed" respectively. - Power-off completed: The Pwr/Conn/Conf status is "n n n" respectively. 3. Re-execute the addboard(8) or the deleteboard(8) command. |
| RTI No. | RTIF2-131213-011 |
| Model | SPARC M10-4S |
| Description | When a SPARC M10-4S or a crossbar box is added using the addfru(8) command, the following message is output and the addition may fail. [Warning:036] Failed to find BB#x. The BB-ID setting and/or the cable connections of the BB#x will be wrong. Please confirm the BB-ID setting and the cable connections. Do you want to try to add BB#x again? [a:add|c:cancel] : |
| Workaround | When the following maintenance menu is output after executing the addfru(8) command, turn on the input power to the SPARC M10-4S or the crossbar box to be added, and execute the next operation (step 2) after 20 minutes. 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]: [How to restore] Input "a" in response to the "[a:add|c:cancel] :" message and re-execute the addfru(8) command. |
| RTI No. | RTIF2-131213-019 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | While the XSCF is starting after being powered on, a watchdog timeout may occur and the XSCF is rebooted. After this reboot is completed, the configuration information of the components mounted on the system cannot be checked by the showhardconf(8) command. Moreover, the following configuration-related messages may be registered in the error log: Msg: Indispensable parts are not installed (PSU). Msg: Indispensable parts are not installed (FAN). Msg: Indispensable parts are not installed (OPNL). Msg: PSU shortage Msg: FAN shortage In this case, the physical partition may not be started. |
| Workaround | There is no effective workaround. [How to restore] Re-execute power off and on. |
| RTI No. | RTIF2-131213-022 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | After a firmware update, when the XCP version is checked with the version(8) command or the XSCF Web interface, the displayed XCP version of a SPARC M10-1, SPARC M10-4, crossbar box (XBBOX), or SPARC M10-4S (BB) may not be the same as the updated XCP version. The following shows an example of firmware update from XCP 2042 to XCP 2052. The XCP version for "XCP0 (Reserve):" of BB#00 is not updated. XSCF> version -c xcp -vXBBOX#80-XSCF#0 (Master) XCP0 (Reserve): 2052 XSCF : 02.05.0002 XCP1 (Current): 2052 XSCF : 02.05.0002 XBBOX#81-XSCF#0 (Standby) XCP0 (Current): 2052 XSCF : 02.05.0002 XCP1 (Reserve): 2052 XSCF : 02.05.0002 BB#00-XSCF#0 XCP0 (Reserve): 2042CMU : 02.05.0002 POST : 1.43.0 OpenBoot PROM : 4.34.0+1.22.0 Hypervisor : 0.27.8 XSCF : 02.04.0002XCP1 (Current): 2052 CMU : 02.05.0002 POST : 1.43.0 OpenBoot PROM : 4.34.0+1.22.0 Hypervisor : 0.27.8 XSCF : 02.05.0002 |
| Workaround | There is no effective workaround. [How to restore] For the SPARC M10-1, the SPARC M10-4, or the 1BB configuration with the SPARC M10-4S, execute the rebootxscf command to reset the XSCF. For the building block configuration, specify the BB-ID of the crossbar box (XBBOX) or the SPARC M10-4S (BB), which was not updated, in the rebootxscf -b BB-ID command, and execute it to reset the XSCF of the specified chassis. |
| RTI No. | RTIF2-131126-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Update of the PCI expansion unit firmware may fail. If it fails, "LINKCARD update is failed" appears in the event log. [Example] SCF:LINKCARD update is failed (LINKCARD=1, bank=0, PCIBOX version=1130: last version=1120) |
| Workaround | There is no effective workaround. Execute the ioxadm -c update command to update the PCI expansion unit firmware again. |
| RTI No. | RTIF2-131112-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If data is transmitted via SSH by the snapshot(8) -t command, this transmission may be delayed by about 10 to 30 minutes in comparison with transfer using USB devices and XSCF Web. |
| Workaround | There is no effective workaround. Even if transfer is delayed, there is no problem with the collected data. |
| RTI No. | RTIF2-131112-013 |
| Model | SPARC M10-4S |
| Description | Suppose that multiple physical partitions (PPARs) are simultaneously started by the poweron -a command. The error message "Error storing configuration variable. LDC is not up Configuration variable setting will not persist after a reset or power cycle" may be output to the OS console after the message "Unable to connect to Domain Service providers." Oracle Solaris may be started without applying the OpenBoot PROM environment variable specified with the setpparparam(8) command. |
| Workaround | There is no effective workaround. Restart the control domain for the physical partition (PPAR) for which the error message was output. |
| RTI No. | RTIF2-131001-002 |
| Model | SPARC M10-4S |
| Description | While a physical partition (PPAR) is operating or when a PPAR is turned off, master/standby XSCF switching may occur. If master/standby switching occurs, the following message is displayed on the console of the master XSCF. Kernel panic - not syncing: MBC Dual ifcut interrupt. |
| Workaround | There is no effective workaround. As a result of this defect, master/standby switching occurs, but this does not affect the system, and the system can be operated continuously. |
| RTI No. | RTIF2-130919-001 |
| Model | SPARC M10-4S |
| Description | In a system composed of several SPARC M10-4S chassis, if input power is turned off and on (AC OFF/ON) on a number of the SPARC M10-4S chassis while some other slave chassis are running, the physical partitions may not start. |
| Workaround | When performing AC OFF/ON, do so on all of the chassis comprising the system. [How to restore] Turn off the input power to all of the chassis comprising the system, and then turn on the input power. |
| RTI No. | RTIF2-130710-001 |
| Model | SPARC M10-4S |
| Description | If XSCF switching is performed using the switchscf(8) command, in rare cases, the standby XSCF may not start. This problem may also occur in any of the following situations. - Only the master XSCF in a system with a building block configuration is rebooted by the rebootxscf(8) command or from XSCF Web. - The master XSCF in a system with a building block configuration is rebooted by a firmware update by the flashupdate(8) command or from XSCF Web. |
| Workaround | There is no effective workaround. [How to restore] Turn off and then turn on the input power supply (AC OFF/ON) to every SPARC M10-4S chassis or execute the replacefru(8) command to perform pseudo replacement (replacement work without replacing any parts) of the SPARC M10-4S that does not start. |
| RTI No. | RTIF2-130516-002 |
| Model | SPARC M10-4S |
| Description | If XSCF switching or an XSCF reboot occurred while the physical partition (PPAR) was being powered off, it may be impossible to turn off the power. |
| Workaround | There is no effective workaround. While powering off the PPAR, do not use the switchscf(8) command for the switching or the rebootxscf(8) command for the XSCF reboot. [How to restore] Turn off the input power, and then turn it on again. (AC OFF/ON) |
| RTI No. | RTIF2-130516-004 |
| Model | SPARC M10-4S |
| Description | If a hardware failure occurs in a 4BB or greater configuration, automatic cluster switching may fail. If 16 or more guest nodes are incorporated into a single cluster, the following warning message may be output to the console of the control domain. SA SA_xscf????.so to test host ??? failed |
| Workaround | If automatic cluster switching fails, follow the procedure in the manual of the cluster software to perform switching manually. |
| RTI No. | RTIF2-130516-006 |
| Model | SPARC M10-4S |
| Description | If XSCF switching occurs while multiple physical partitions (PPARs) are being powered on at the same time, it may take more time than usual to power them on. |
| Workaround | There is no effective workaround. Do not switch an XSCF by using the switchscf(8) command while PPARs are being powered on. |
| RTI No. | RTIF2-130410-001 |
| Model | SPARC M10-4S |
| Description | Suppose that for the system connected to a crossbar box, you are powering on or off the physical partition (PPAR) that is not assigned to the maintenance-target FRU, and you execute the diagxbu(8) or testsb(8) command. In this case, the diagnosis of a system board (PSB) may fail during the PSB power-off, and the following message may be output. [Warning:010] An internal error has occurred. |
| Workaround | There is no effective workaround. Execute the showboards(8) command to check that the [Pwr] field of the relevant PSB is set to "n". If the field is set to "y", execute the showboards(8) command every few minutes to check that the field changes to "n". |
| RTI No. | RTIF2-130410-002 |
| Model | SPARC M10-4S |
| Description | The switching of an XSCF may fail if the XSCF is switched by executing the switchscf(8) command while a physical partition (PPAR) is being powered on. |
| Workaround | Do not switch an XSCF by using the switchscf(8) command while a PPAR is being powered on. |
| RTI No. | RTIF2-130410-003 |
| Model | SPARC M10-4S |
| Description | If a physical partition (PPAR) is powered on in a system that satisfies all the following conditions, another PPAR may also be powered on. - Remote power management is enabled with the setremotepwrmgmt(8) command. - When created, a node does not have a set SubNodeID in the management items for remote power management. - Multiple PPARs are configured. |
| Workaround | - When remote power management is not necessary Disable remote power management with setremotepwrmgmt -c disable and then delete the remote power management setting with the clearremotepwrmgmt(8) command. - When remote power management is necessary If the system has multiple PPARs, create a management file for remote power management by specifying a PPAR-ID as a SubNodeID, and then register the remote power management setting with setremotepwrmgmt -c config. |
| RTI No. | RTIF2-130329-005 |
| Model | SPARC M10-1 |
| Description | When you turn on the input power supply in the SPARC M10-1, the XSCF READY LED remains blinking and the system may not start. |
| Workaround | There is no effective workaround. Power off the input power supply and then power it on again. |
| RTI No. | RTIF2-130305-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | "The limit of power has been exceeded" is registered in the event log if you perform the following. Execute the setpowercapping(8) command to set the power capping function to "Enable," the upper limit of power consumption to "powerlimit_p" (percentage), and the window time for exceeding the upper limit of power consumption to "none." Then, turn on the input power supply or turn off the power to the physical partition (PPAR). |
| Workaround | There is no effective workaround. Ignore this event log. |
| RTI No. | RTIF2-130305-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If an error in the CPU or memory is detected and if the XSCF is switched while the XSCF is reporting error information to the control domain, the error information may not be reported again to the control domain. Because of this, the error information displayed with the showlogs error command is not displayed in the Fault Report output by the fmdump command. |
| Workaround | There is no effective workaround. Perform maintenance according to the FRU displayed by the showlogs error command. |
| RTI No. | RTIF2-130305-007 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | A FRU registered in the error log is displayed as "PPAR#30" if the configuration error of the system board (PSB) is detected when executing the testsb(8) command or diagxbu(8) command. |
| Workaround | There is no effective workaround. Maintain the applicable PSB of the SPARC M10 system chassis. |
| RTI No. | RTIF2-130305-013 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | While the XSCF is starting, watchdog timeout may occur, which may cause the XSCF to be reset. |
| Workaround | Perform the following procedure. 1. If Oracle Solaris is running, shut it down. 2. Confirm that Oracle Solaris has been shut down, and then turn off and on (AC OFF/ON) the input power of the system. When turning off/on the input power, power off the system, wait at least 30 seconds, and then power on the system. If the XSCF does not start even after the system input power is cycled, replace the CPU memory unit lower (CMUL) or the motherboard unit (MBU). |
| RTI No. | RTIF2-130305-020 |
| Model | SPARC M10-4S |
| Description | If an XSCF panic or hang occurs, "XSCF hang-up is detected" may be posted many times in the error log. |
| Workaround | There is no effective workaround. Ignore duplicate notifications with the same time in the log, considering that they have the same cause. |
| RTI No. | RTIF2-130305-022 |
| Model | SPARC M10-4S |
| Description | The poweron(8) command may fail with the output of the following message if "XSCF hang-up is detected" was detected in the error log and the showboards(8) command found an "unknown" system board (PSB). The same happens even with a power-on instruction from XSCF Web, APCS, or remote power management. Not powering on : An internal error has occurred. Please contact your system administrator. |
| Workaround | There is no effective workaround. Use the showboards(8) command to replace the XSCF of the "unknown" PSB. |
| RTI No. | RTIF2-130305-025 |
| Model | SPARC M10-4S |
| Description | If the poweroff(8) command is executed on a system that has more than one physical partition (PPAR), the processing takes time because the PPARs are powered off one by one. Depending on the system configuration, it may take about one hour. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-130219-004 |
| Model | SPARC M10-4S |
| Description | If an error occurs with a crossbar unit mounted on a crossbar box, many instances of "failed to read/write interrupt mask register" may be registered in the error log. |
| Workaround | There is no effective workaround. Power off the physical partition (PPAR) and replace the crossbar unit in the crossbar box. |
| RTI No. | RTIF2-130219-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If you reboot an XSCF by using the flashupdate(8) or rebootxscf(8) command while a physical partition (PPAR) is being powered on, the POST may stop in a state where the diagnosis is completed (Initialization Complete). |
| Workaround | There is no effective workaround. [How to restore] Execute the reset por command, or power off the PPAR by using the poweroff -f command, and then power it on again. |
| RTI No. | RTIF2-130109-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If you use the setpcl(8) command to change the LSB number of a SPARC M10 system connected to a PCI expansion unit, and then you start Oracle Solaris in a logical domain configuration, you cannot display the configuration information for the PCI expansion unit by executing the showhardconf(8) command. |
| Workaround | Use the setdomainconfig(8) command to set the logical domain configuration to the factory-default, and power on the physical partition (PPAR). Then, configure the logical domain again. |
Workaround for RTIF2-140304-007
If a PSU is replaced with the replacefru(8) command, after mounting the new PSU, wait at least 30 seconds before pressing the [f] key for the menu of the replacefru(8) command.
| Do you want to continue?[r:replace|c:cancel] :r Please execute the following steps: 1) Remove PSU#n. 2) Execute either the following: 2-1) After installing the exchanged device, please select 'finish'. 2-2) If you want to suspend the maintenance without exchanging device, please select 'cancel'. [f:finish|c:cancel] :f |
[How to restore]
If no workaround is implemented and the status of both PSUs is "Deconfigured," active replacement of the PSUs cannot be done with the replacefru(8) command.
If no workaround is implemented and the status of both PSUs is "Deconfigured," active replacement of the PSUs cannot be done with the replacefru(8) command.
| Maintenance/Replacement Menu Please select a FRU to be replaced. No. FRU Status --- ------------------- -------------- 1 /PSU#0 Deconfigured 2 /PSU#1 Deconfigured ------------------------------------------------------------------------------ Select [1,2|b:back] :2 [Warning:307] PSU#1 cannot be replaced. Please verify the configuration. Select [1,2|b:back] :2 [Warning:307] PSU#1 cannot be replaced. |
To restore the system, first remove each replaced PSU without using the replacefru(8) command. Then, use the replacefru(8) command to replace the PSUs.
< Previous Page | Next Page >