Problems Resolved in XCP 2220
Problems Resolved in XCP 2220
The following table lists the problems resolved in XCP 2220.
| RTI No. | RTIF2-201119-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose that you specify LDAP as the user authentication lookup by the setlookup command without configuring the LDAP server. Then, XSCF login using an XSCF user account managed with the LDAP over SSL service or the Active Directory service is not possible. |
| Workaround | There is no effective workaround. To specify LDAP for the user authentication lookup, configure the LDAP server. |
| RTI No. | RTIF2-201118-012 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When "PCI Express lane is degraded" is registered in the error log of the PCI expansion unit, a FRU may be mistakenly displayed as the target. |
| Workaround | There is no effective workaround. Update the PCI expansion unit firmware to 1170 or later, and the XCP firmware to XCP 2220 or later. |
| RTI No. | RTIF2-201118-013 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If input power to the PSU of the PCI expansion unit is disconnected (AC OFF), an Information level error log for the PSU should be registered. Instead, an Alarm level error log is incorrectly registered. [Example] XSCF> showlogs error -rMV Date: Nov 13 16:39:30 JST 2013 Code: 80000400-00cb000000ff0000ff-1100002a0000000000000000 Status: Alarm Occurred: Nov 13 16:39:27.226 JST 2013 FRU: /MBU/PCI#2/PCIBOX#3001/PSU#1 Msg: AC FAIL |
| Workaround | There is no effective workaround. Update the PCI expansion unit firmware to 1170 or later, and the XCP firmware to XCP 2220 or later. There is no impact on system operation from this phenomenon. |
| RTI No. | RTIF2-141106-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | For XCP 2210 or earlier, the error log "PCI Express link up failed" may be erroneously registered, and an on-board I/O device or a PCI slot may be degraded if a physical partition (PPAR) is powered on/off after any of the following error logs related to abnormal temperature is registered. - Temperature out of range error - High temperature at SW - Hardware access error.(thermal sensor) In these error logs, the first two bytes of the second field in [Code:] has the value of "0013". |
| Workaround | There is no effective workaround. [How to restore] Turn off the system input power, then restore the power (AC OFF/ON). |
| RTI No. | RTIF2-140804-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the fan speed is switched due to a change in the intake air temperature, an error log indicating an abnormal fan speed may be erroneously registered for a fan that is not faulty. |
| Workaround | There is no effective workaround. [How to restore] Execute the replacefru(8) command, and select the fan registered in the error log. Follow the replacement instructions on the maintenance menu, without replacing the fan. |
| RTI No. | RTIF2-140606-005 |
| Model | SPARC M10-4S |
| Description | Suppose that the testsb(8) command running for a system board (PSB) diagnosis detects one of the errors listed below during the period between power-off and power-on of the SPARC M10 Systems chassis or crossbar box chassis. In this case, the command terminates, leaving the power to the chassis on. - The DC-DC converter (DDC) in the chassis is faulty. Error log: Msg: Power-on failure - The circuit that monitors cooling components within the chassis is abnormal. Error log: Msg: LLC protection circuit test error - A crossbar cable is connected to the crossbar unit (XBU) within the chassis in an invalid combination. Error log: Msg: XB CABLE configuration error You can determine the occurrence of this phenomenon from the above error log and the output of the showboards(8) command. If this phenomenon has occurred, the command outputs "y" for [Pwr] and "Failed" for [Test]. [Example] If the power to the SPARC M10-4S chassis is on and the system board diagnosis indicates an error XSCF> showboards -aPSB PPAR-ID(LSB) Assignment Pwr Conn Conf Test Fault---- ------------ ----------- ---- ---- ---- ------- --------00-0 00(00) Assigned y n n Failed Faulted |
| Workaround | There is no effective workaround. Check the error log and perform maintenance on the component. |
| RTI No. | RTIF2-140605-007 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | For XCP 2041 or later, when an error log for a configuration error in a power supply unit (PSU) is registered, inappropriate message text is registered for this log. Although the message text should indicate the mixing of different AC input voltages (100 V and 200 V), it indicates the existence of an incorrect combination of PSU types. [Example] Message text (to the right of "Msg:") inappropriately registered when different AC input voltages of 100 V and 200 V are mixed. Code: 80000000-0001020000ff0000ff-018af0220000000000000000 Status: Alarm Occurred: May 27 11:22:00.0000 JST 2014 FRU: /MBU Msg: Wrong PSU is installed The correct message indicating the mixing of different AC input voltages is as follows: Msg: PSUs detected 100V and 200V at AC inputs |
| Workaround | There is no effective workaround. Execute the showlogs error command and check the value of the third and fourth bytes in the third field in [Code:]. Depending on this value, take appropriate action by following the correct message indicated below instead of the output message. - If the value of the bytes is "f022" Different AC input voltages of 100 V and 200 V are mixed on the PSU. Check the PSU for AC input connection status. - If the value of the bytes is not "f022" The combination of PSU types is incorrect. Contact a field engineer. |
| RTI No. | RTIF2-140507-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In a SPARC M10 system with XCP 2043 or later, a disk is removed from a hardware RAID (RAID1 or RAID1E), and the resulting disk failure is detected. If the subsequent power-off/on, reboot of Oracle Solaris, or execution of the shutdown -i0 command causes a state transition of the Open Boot PROM, the disk is not placed in the original RAID volume but in another RAID volume, even after disk restoration. Moreover, the original RAID volume stays in a degraded state. |
| Workaround | Execute any of the following procedures according to the circumstances. - If one of the disks composing a RAID volume fails while the system is running, replace the disk while the system is running, without restarting Oracle Solaris. - If one of the disks composing a RAID volume is removed while the system is running, remount the removed disk while the system is running, without restarting Oracle Solaris. - If one of the disks composing a RAID volume is removed while the PPAR is powered off, remount the removed disk while the PPAR is in the powered off state. [How to restore] Perform the following procedure if this symptom occurs: 1. Remove the newly created RAID volume. 2. Set up the target disk as "hot spare". When the "hot spare" feature is enabled, the disk will be automatically placed in the original RAID volume. Meanwhile, see "F.5 Creating a Hot Spare of a Hardware RAID Volume" and "F.6 Deleting a Hot Spare of a Hardware RAID Volume" in the Fujitsu SPARC M12 and Fujitsu M10/SPARC M10 System Operation and Administration Guide for the procedures of removing a volume or setting up a hot spare. |
| RTI No. | RTIF2-140507-002 |
| Model | SPARC M10-4S |
| Description | If the system board is deleted by dynamic reconfiguration of physical partitions, Oracle Solaris on the domain may panic, or Hypervisor may abort. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140507-015 |
| Model | SPARC M10-4, SPARC M10-4S |
| Description | If the showhardconf(8) command is executed in a system configuration with at least 3 BBs or a crossbar box, the wrong information may be output at the FRU-Part-Number of the crossbar cable. [Example] For crossbar cable number R0: Incorrect: CBL#R0 Status:Normal; + FRU-Part-Number:@@@D00Q@; Ver:0020h; + Type:Optic; Length: 2; Correct: CBL#R0 Status:Normal; + FRU-Part-Number: ALLT03FQPE; Ver:0020h; + Type:Optic; Length: 2; |
| Workaround | There is no effective workaround. There is no effect of this wrong display on the system. |
| RTI No. | RTIF2-140507-017 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If the XSCF is reset using the rebootxscf(8) command, the XSCF may stop due to an XSCF failure. |
| 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-140507-018 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the system is in the initialized state, the XSCF may not start even after turning on the input power. |
| Workaround | There is no effective workaround. [How to restore] Replace the CPU memory unit lower (CMUL), the XSCF unit (XSCFU), or the motherboard unit (MBU). |
| RTI No. | RTIF2-140418-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The Dynamic Resource Management(DRM) of Oracle VM Server for SPARC does not work. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140407-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In a system configuration with a connected PCI expansion unit, you may update the XCP firmware or reset the XSCF with the physical partition (PPAR) powered on. In this case, the PCI expansion unit information is not output in the results from an executed ioxadm(8) or showhardconf(8) command. Or, the PCI expansion unit can no longer be controlled with the ioxadm(8) command. |
| Workaround | There is no effective workaround. [How to restore] Perform one of the following operations: - Power off the PPAR and then power it on again. - Use PCI hot plug (PHP) to remove the link card from the system and reinstall it. |
| RTI No. | RTIF2-140407-004 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose you execute the setaudit -a command to set the user audit policy, and then reset the XSCF. In this case, the audit policy of the registered user may be replaced by the audit policy of the user account "default," and the audit policy of the registered user may be erased. This occurs when the user account "default" has no set audit policy. [Example] Setting an audit policy for yyyyy user XSCF> setaudit -a yyyyy=disable XSCF> showaudit all --- Omitted --- User policy: yyyyy disabled Events: AEV_AUDIT_START enabled XSCF> rebootxscf -a XSCF> showaudit all --- Omitted --- User policy: default disabled Events: AEV_AUDIT_START enabled |
| Workaround | If user account "default" is not displayed for [User Policy:] in the output results from the showaudit all command, execute the setaudit -a command to set the audit policy of the user account "default". [Example] Set the audit policy for the user account "default". XSCF> setaudit -a yyyyy=disable [How to restore] Perform the following procedure. 1. Execute the setaudit -a command to reset the user audit policy that had been used as the audit policy of the user account "default". 2. Execute the rebootxscf(8) command to reset the XSCF. 3. Execute the showaudit all command to confirm that the set user audit policy is displayed for [User Policy:]. |
| RTI No. | RTIF2-140402-002 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In the search function for each log in the [XSCF] - [Logs] menu on XSCF Web, if you click the [Search] button with both the [Start] and [End] times set to perform a search, a message indicating an error in the specified period may be output and it may not be possible to perform the search. |
| Workaround | Use the showlogs(8) command in the XSCF shell. |
| RTI No. | RTIF2-140314-002 |
| Model | SPARC M10-4S |
| Description | In the case of XCP 2210 applied to a SPARC M10-4S attached to a crossbar box (XBBOX), if the crossbar cable is degraded due to some problem, the following symptom may occur while the system is running. - If a failure occurs in the crossbar unit (XBU) of the crossbar box (XBBOX), it may not be detected and the physical partition may hang. Failure of crossbar cable can be confirmed by any of the following error logs: FRU: /BB#n/XBU#x/CBL#y,/BB#n/XBU#x,/XBBOX#m/XBU#x Msg: XB-XB interface fatal bus protocol error Or FRU: /BB#n/XBU#x/CBL#y,/BB#n/XBU#x,/XBBOX#m/XBU#x Msg: XB-XB interface timeout error Or FRU: /BB#n/XBU#x/CBL#y,/BB#n/XBU#x,/XBBOX#m/XBU#x Msg: XB-XB interface link-up error |
| Workaround | If a problem with any crossbar cable has occurred, stop all PPARs immediately and replace the crossbar cable. [How to restore] 1. Stop all PPARs. If any of them cannot be stopped normally, stop it forcibly. 2. Replace the degraded crossbar cable. 3. Diagnose the hardware with the testsb -a command and check whether there is any XBU failure in the XBBOX. 4. If there is any failure in the XBU, replace it. |
| RTI No. | RTIF2-140312-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Configuration of SNMP fails when it is done from the [SNMP] or the [SNMP Security] menu of XSCF Web. |
| Workaround | Do not configure SNMP from XSCF Web. Use the following XSCF shell commands to configure SNMP. - setsnmp(8) - setsnmpusm(8) - setsnmpvacm(8) |
| RTI No. | RTIF2-140310-001 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When executed to import a server certificate, the setldap -c command will end with an error and importing will fail. |
| Workaround | There is no effective workaround when the setldap(8) command is used. Use the encryption feature of LDAP (LDAP over SSL) with the setldapssl(8) command. |
| RTI No. | RTIF2-140227-003 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | After the detection of degradation of a SPARC M10 chassis, if reboot or AC OFF/ON is executed on the physical partition, "PSU shortage" may be mistakenly registered in the error log. Moreover, the PSU is marked as failed due to this error. |
| Workaround | There is no effective workaround. [How to restore] Execute the following procedures. - If [Status] of the power supply unit (PSU) has not become "Faulted": 1. Eliminate the cause of the degradation of the SPARC M10 chassis. 2. If a "Failure" mark is attached to the PSU, perform AC OFF/ON to remove it. - If [Status] of the power supply unit (PSU) has become "Faulted": 1. Replace the PSU. 2. Perform AC OFF/ON to remove the "Failure" mark from the PSU. |
| RTI No. | RTIF2-140227-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | If [Ctrl]+[C] is pressed when any of the following commands is running, in some very rare cases, the command may not terminate Moreover, other running commands executed by other logged-in users also may not terminate. ping(8), setservicetag(8), shownetwork(8), showntp(8), showpacketfilters(8), showservicetag(8), traceroute(8) |
| Workaround | There is no effective workaround. [How to restore] Perform AC OFF/ON. |
| RTI No. | RTIF2-140227-007 |
| Model | SPARC M10-4S |
| Description | When the SSCP IP address of an unmounted SPARC M10-4S chassis is set up using the setsscp(8) command, the showsscp(8) command displays the "Not installed" message, and the set IP address cannot be confirmed. Therefore, before adding a SPARC M10-4S chassis or crossbar box with the addfru(8) command, you cannot confirm the SSCP IP address of the added chassis with the showsscp(8) command. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140227-008 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | When the lockout feature of user accounts is enabled with the setloginlockout(8) command, if three logins to XSCF Web are performed with the same user account, further logins are disabled for the duration of the set lockout time. |
| Workaround | Disable the lockout feature of user accounts. |
| RTI No. | RTIF2-140221-003 |
| Model | SPARC M10-4S |
| Description | If the addboard(8) or deleteboard(8) command is executed using the DR feature, addition or removal of system boards using the DR feature may fail, displaying the following message: "Failed to evacuate board resources". |
| Workaround | Re-execute the addboard(8) or deleteboard(8) command. If it fails again, either restart only the control domain or execute the rebootxscf -a command to reset the XSCF. After that, re-execute the addboard(8) or deleteboard(8) command, using the DR feature. |
| RTI No. | RTIF2-140212-002 |
| Model | SPARC M10-4S |
| Description | If the crossbar cable in the crossbar unit (XBU) of the SPARC M10-4S fails, the name of the failed component is wrongly displayed with the showstatus(8) command. The numbers and letters in the part number are displayed in reverse. [Example] For crossbar cable number 0L Wrong display: CBL#L0 Status: Deconfigured; Right display: CBL#0L Status: Deconfigured; |
| Workaround | There is no effective workaround. Read the part numbers accordingly. |
| RTI No. | RTIF2-140212-004 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | The OID information of scfPPAROsMachine in the definition file of the XSCF extension MIB should have a value of "sun4v" but instead contains CMU firmware version information like "02090000". |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-140212-006 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | In the case of SNMPv1 or SNMPv2, if the trap host name, which contains the XSCF host name, is registered by the setsnmp(8) command, the trap host is not displayed by the showsnmp(8) command. [Example of non-displaying with the showsnmp(8) command] XSCF host name: example.com Trap host name: test.example.com |
| Workaround | Either specify a trap host name which does not contain the XSCF host name or specify the IP address of the trap host. |
| RTI No. | RTIF2-140212-022 |
| Model | SPARC M10-1, SPARC M10-4, SPARC M10-4S |
| Description | Suppose you execute the setsnmp addtraphost command with -t inform specified to register a trap host. Then, the UDP address of a trap that is reported to that trap host will become the IP address (physical IP address) assigned to the XSCF-LAN, instead of a takeover IP address (virtual IP address). This symptom occurs when a takeover IP address is set up. |
| Workaround | There is no effective workaround. |
| RTI No. | RTIF2-130806-001 |
| Model | SPARC M10-1, SPARC M10-4S |
| Description | Suppose that the XSCF is configured as an NTP client and is synchronized with the upper level NTP server time. If you replace one of FRUs listed below for each model and then power on the physical partition (PPAR), the Oracle Solaris time may become January 1, 2001. [SPARC M10-1] - Motherboard unit (MBU) - PSU backplane (PSUBP) [SPARC M10-4S] - crossbar backplane unit (XBBPU) - XSCF unit (XSCFU) You can determine the occurrence of this problem by executing the showdateoffset(8) command. If an extremely large value (400 million seconds or more) is displayed in [Domain Date Offset], this problem has occurred. [Example] XSCF> showdateoffset -aPPAR-ID Domain Date Offset00 424915200 sec01 424915200 sec02 424915200 sec03 424915200 sec: 15 424915200 sec |
| Workaround | Use the following procedure to replace a FRU listed in "Description." - If the NTP client setting for the XSCF is disabled This problem will not occur. Perform the ordinary replacement procedure. - If the NTP client setting for the XSCF is enabled 1. Disconnect the LAN cable from the XSCF-LAN port and then perform replacement. 2. After the XSCF starts, connect the serial cable to the serial port. Do not connect the LAN cable at this time. 3. Disable the NTP client setting for the XSCF. You need to reboot the XSCF to make your change effective. 4. Execute the setdate(8) command to set the XSCF time. After this, the XSCF is rebooted. 5. Connect the LAN cable to the XSCF-LAN port. 6. Enable the NTP client setting for the XSCF. You need to reboot the XSCF to make your change effective. [How to restore] After replacing the FRU listed in "Description," perform the following: When you power on the physical partition, the Oracle Solaris time becomes January 1, 2001. Start up Oracle Solaris in single user mode and set the time. |
< Previous Page | Next Page >