Hardware Issues

This section describes issues related to SPARC T4-1 server components.

Maximizing Memory Bandwidth

To maximize memory bandwidth, Oracle recommends that only fully-populated memory configurations—as opposed to 1/4- or 1/2-populated configurations—be considered for performance-critical applications.

For specific memory installation and upgrade instructions, see the SPARC T4-1 Server Service Manual.

Direct I/O Support

Only certain PCIe cards can be used as direct I/O endpoint devices on an I/O domain. You can still use other cards in your Oracle VM Server for SPARC environment, but they cannot be used with the Direct I/O feature. Instead, they can be used for service domains and for I/O domains that have entire root complexes assigned to them.

For the most up-to-date list of supported PCIe cards, refer to:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=1325454.1

Use Links Labeled SPARC T3 to Download sas2ircu Firmware and Documentation for SPARC T4 Servers

To download sas2ircu firmware and documentation for SPARC T4-1 and T4-2 servers from the current LSI web site, you must use links labeled SPARC T3-1 and T3-2. The software and documentation is the same for both sets of servers.

This is the web site for downloading sas2ircu firmware from LSI:

http://www.lsi.com/sep/Pages/oracle/index.aspx

This is the web site for downloading sas2ircu documentation from LSI:

http://www.lsi.com/sep/Pages/oracle/sparc_t3_series.aspx

Sun Type 6 Keyboards Are Not Supported By SPARC T4 Series Servers

Sun Type 6 keyboards cannot be used with SPARC T4 series servers.

Caution Needed When Removing a SATA Data Cable From a Backplane Connector

When disconnecting the SATA data cable from the disk backplane, pull the cable straight back, in a perpendicular direction away from the backplane.

---

Caution - Do not rock or twist the cable in any other direction. Doing so could damage the integrity of the data cable connection.

---

Caution Needed When Handling the Connector Board

Use caution when handling the connector board to avoid pressing your hand against the pointed end of the guide pin that's located below the mounting bracket. The guide pin is indicated by an arrow in the following figure.

Server Panics When Booting From a USB Thumbdrive Attached to the Front USB Ports (Bug ID 15667682)

When attempting to boot a USB thumbdrive inserted in either front USB port (USB2 or USB3), the server might panic.

Workaround: Use the server's rear USB ports (USB0 or USB1) whenever booting from an external USB device.

PSH Might Not Clear a Retired Cache Line on a Replaced Motherboard (Bug ID 15705327, Bug ID 15713018)

When a motherboard is replaced to repair a faulty CPU, PSH might not clear retired cache lines on the replacement FRU. In such cases, the cache line remains disabled.

Workaround: Manually clear the disabled cache line by running the following command:

# fmadm repaired /SYS/MB/CMP0

PCIe Correctable Errors Might Be Reported (Bug ID 15720000, Bug ID 15722832)

In rare cases, PCIe devices might generate I/O errors that are identified and reported by PSH. For example:

--------------- ------------------------------------  -------------- ---------
TIME            EVENT-ID                              MSG-ID         SEVERITY
--------------- ------------------------------------  -------------- ---------
Aug 10 13:03:23 a7d43aeb-61ca-626a-f47b-c05635f2cf5a  PCIEX-8000-KP  Major
 
Host        : dt214-154
Platform    : ORCL,SPARC-T3-1B  Chassis_id  :
Product_sn  :
 
Fault class : fault.io.pciex.device-interr-corr 67%
              fault.io.pciex.bus-linkerr-corr 33%
Affects     : dev:////pci@400/pci@1/pci@0/pci@c
              dev:////pci@400/pci@1/pci@0/pci@c/pci@0
                  faulted but still in service
FRU         : "/SYS/MB" (hc://:product-id=ORCL,SPARC-T3-1B:product-sn=1052NND107:server-id=dt214-154:chassis-id=0000000-0000000000:serial=1005LCB-1052D9008K:part=541-424304:revision=50/chassis=0/motherboard=0) 67%
              "FEM0" (hc://:product-id=ORCL,SPARC-T3-1B:product-sn=1052NND107:server-id=dt214-154:chassis-id=0000000-0000000000/chassis=0/motherboard=0/hostbridge=0/pciexrc=0/pciexbus=1/pciexdev=0/pciexfn=0/pciexbus=2/pciexdev=12/pciexfn=0/pciexbus=62/pciexdev=0) 33%
                  faulty
 
Description : Too many recovered bus errors have been detected, which indicates
              a problem with the specified bus or with the specified
              transmitting device. This may degrade into an unrecoverable
              fault.
              Refer to http://sun.com/msg/PCIEX-8000-KP for more information.
 
Response    : One or more device instances may be disabled
 
Impact      : Loss of services provided by the device instances associated with
              this fault
 
Action      : If a plug-in card is involved check for badly-seated cards or
              bent pins. Otherwise schedule a repair procedure to replace the
              affected device.  Use fmadm faulty to identify the device or
              contact Sun for support.

These errors might be an indication of a faulty or incorrectly seated device. Or these errors might be invalid.

Workaround: Ensure that the device is properly seated. If the errors continue, apply patch 147705-01 or higher.

SPARC T3 and T4 Platforms Might See Dropped or Doubled Character Input From USB Keyboards (Bug ID 15700526, Bug ID 15728507)

On Oracle's SPARC T3 and T4 servers, all USB ports/connectors available to users are connected to an internal USB 2.0 (ehci) controller through an onboard USB 2.0 hub.

When a full/low speed USB 1.0/1.1 keyboard and mouse are connected to a USB port through this USB 2.0 hub, keyboard input might drop characters or might display double characters.

Workaround: Currently, a workaround has been implemented for this issue where an internal USB hub is manually bound to the ohci (USB 1.0/1.1) driver. This binding causes a variable named ehci_forced_port_to_companion to instruct the ehci (USB 2.0) driver to transfer ownership of a specific port on the USB controller to the ohci (1.0/1.1) driver. Once the ohci driver is bound to a particular port on the USB controller, the ohci driver will also be used by the internal USB hub connected to that port and all USB connectors on that hub.

This workaround is available in the following forms:

• Oracle Solaris 11 OS – Oracle Solaris 11 Support Repository Update 3 (SRU3)

• Oracle Solaris 10 8/11 – Patch 147004-03

For earlier supported versions of Oracle Solaris 10, apply the Solaris 10 8/11 SPARC Bundle, followed by patch 147004-03.

Supplementary Notes

On T3-1, T4-1, T3-2, and T4-2, the rear USB connectors as well as the virtual keyboard, virtual mouse, virtual CD-ROM, and virtual USB ethernet connection to the service processor (a.k.a RKVMS) are all beneath a hub connected to port 2 on the USB controller.

The front USB connectors are connected through a hub to port 4 of the USB controller.

Likewise, on the T3-4 and T4-4 platforms, the rear USB connector is beneath a hub that is connected to port 3 of the USB controller and the front USB connector and the virtual mouse, keyboard, CD-ROM and virtual USB ethernet connection to the service processor are beneath a hub that is connected to port 2 of the USB controller.

To use a physical keyboard and mouse with this workaround, apply the fix (either patch 147004-03 or SRU3) and then perform the following recommended steps:

• On SPARC T3-1, T4-1, T3-2, and T4-2 systems:

  1. Connect the input devices to a front USB connector.

  2. Add the following line to /kernel/drv/ehci.conf:

  ehci-port-forced-to-companion = 4

  3. Reboot.

• On SPARC T3-4 and T4-4 systems:

  1. Connect the input devices to a rear USB connector.

  2. Add the following line to /kernel/drv/ehci.conf:

  ehci-port-forced-to-companion = 3

  3. Reboot.

To use a physical keyboard and mouse with this workaround, first apply the fix (either patch 147004-03 for Oracle Solaris 10 or SRU3 for Oracle Solaris 11) and then add the following line to /kernel/drv/ehci.conf and reboot:

ehci-port-forced-to-companion = 2

All other devices connected to the hub that services the virtual keyboard and mouse will be forced to operate at the lower USB 1.0/1.1 speed. These include:

• The virtual USB ethernet connection to the service processor.

• The physical USB connectors:

  • Rear conectors on the T3-1, T4-1, T3-2, and T4-2 servers.

  • Front connectors on the T3-4 and T4-4 servers.

When these devices do not come up, messages similar to the following will be displayed on the console and written to system logs:

WARNING: /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,1/hub@1/hub@3 (hubd4): 
Connecting device on port 2 failed

WARNING: /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,1/hub@1/hub@3 (hubd4):
Connecting device on port 3 failed

---

Caution - At this time, there is no fix or workaround for the failure of these devices to come up when the missing micro-frame workaround is configured to support a virtual keyboard and mouse.

---

For this reason, you should limit use of following USB ports when using virtual keyboard and mouse functionality:

• Rear USB connectors on the T3-1, T4-1, T3-2, and T4-2

• Front USB connectors on the T3-4 and T4-4

All other virtual devices (such as virtual keyboard and virtual mouse) will continue to function, but will be limited to operating at the lower speed.

L2 Cache UEs Are Sometimes Reported as Core Faults Without Any Cache Line Retirements (Bug ID 15731176)

When a processor cache line encounters an uncorrectable error (UE) the fault manager is supposed to attempt to retire the cache line involved in the error. Because of this defect, the fault manager might not retire the faulty cache line and instead report the entire chip as faulted.

Workaround: Schedule a replacement of the FRU containing the faulty component. For additional information about UEs in processor cache lines, search for message ID SUN4V-8002-WY on the Oracle support site, http://support.oracle.com.

Upon a Reboot After an Unrecoverable Hardware Error, CPUs Might Not Start (Bug ID 15733431)

In rare cases, if the server or sever module experiences a serious problem that results in a panic, when the server is rebooted, a number of CPUs might not start even though the CPUs are not faulty.

Example of the type of error displayed:

rebooting...
Resetting...
 
ERROR: 63 CPUs in MD did not start

Workaround: Log in to Oracle ILOM on the SP and then power cycle by typing:

-> stop /SYS
Are you sure you want to stop /SYS (y/n)? y
Stopping /SYS
-> start /SYS
Are you sure you want to start /SYS (y/n) ? y
Starting /SYS

reset /SYS Operations Can Cause the SAS Controller to Disappear (Bug ID 15737475)

During an Oracle ILOM reset /SYS command, a SAS controller might not initialize correctly. In such cases it might lose contact with the target disk devices. The error message might appear as follows:

{0} ok boot disk
Boot device: /pci@400/pci@1/pci@0/pci@4/scsi@0/disk@p0  File and args: ERROR: 
boot-read fail
 
Can't locate boot device
{0} ok

If a data disk is not available after performing a reset /SYS, you can use the OBP command probe-scsi-all to verify if your SAS controllers are present. The following example shows the output that you should see with probe-scsi-all:

{0} ok probe-scsi-all
/pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,2/hub@2/hub@3/storage@2
  Unit 0   Removable Read Only device    AMI     Virtual CDROM   1.00
 
/pci@400/pci@2/pci@0/pci@4/scsi@0
 
FCode Version 1.00.56, MPT Version 2.00, Firmware Version 9.00.00.00
 
Target 9
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50005ba000f  SASAddress 5000c50005ba000d  PhyNum 0
Target a
  Unit 0   Removable Read Only device   TSSTcorp CDDVDW TS-T633A  SR00
  SATA device  PhyNum 6
Target b
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f76db7  SASAddress 5000c50016f76db5  PhyNum 1
Target c
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f765ef  SASAddress 5000c50016f765ed  PhyNum 2
Target d
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f7833b  SASAddress 5000c50016f78339  PhyNum 3
 
/pci@400/pci@1/pci@0/pci@4/scsi@0
 
FCode Version 1.00.56, MPT Version 2.00, Firmware Version 9.00.00.00
 
Target 9
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0868    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f777df  SASAddress 5000c50016f777dd  PhyNum 0
Target a
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f7818b  SASAddress 5000c50016f78189  PhyNum 2
Target b
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f758ff  SASAddress 5000c50016f758fd  PhyNum 3 
Target c
  Unit 0   Disk   SEAGATE  ST914603SSUN146G 0B70    286739329 Blocks, 146 GB
  SASDeviceName 5000c50016f7703f  SASAddress 5000c50016f7703d  PhyNum 1
 
{0} ok

If you are missing either of the following lines, you might be experiencing this error (CR 7082665):

• /pci@400/pci@2/pci@0/pci@4/scsi@0

• /pci@400/pci@1/pci@0/pci@4/scsi@0

As an alternative test of this error condition, you can use the format(1) command in Oracle Solaris to list all disks available to the operating system. If one of your data disks is not present after performing a reset /SYS and booting the operating system, you may be experiencing this error (CR 7082665).

Workaround: At the Oracle ILOM prompt first type the stop /SYS command and then the start /SYS command. If the issue persists beyond several power cycles, contact your authorized Oracle Service Provider.

SAS Command Might Fail to Complete When Certain SAS Devices Are Put Under Heavy Load (Bug ID 15802084)

When certain SAS devices are placed under heavy load, a SCSI Bus Reset might occur. The SCSI bus reset will result in one or more WARNING messages being written to the system log file, /var/adm/messages. The following is an example of the WARNING message you might see:

scsi: [ID 243001 kern.info] /pci@400/pci@2/pci@0/pci@4/scsi@0 (mpt_sas1):
mptsas_handle_event_sync: IOCLogInfo=0x31120303
scsi: [ID 243001 kern.info] /pci@400/pci@2/pci@0/pci@4/scsi@0 (mpt_sas1):
mptsas_handle_event: IOCLogInfo=0x31120303
scsi: [ID 243001 kern.info] /pci@400/pci@2/pci@0/pci@4/scsi@0 (mpt_sas1):
mptsas_check_scsi_io: IOCStatus=0x4b IOCLogInfo=0x31120303
scsi: [ID 243001 kern.info] /scsi_vhci (scsi_vhci0):
/scsi_vhci/disk@g5000c5003bee5ae3 (sd6):
Command failed to complete (4) on path mpt_sas3/disk@w5000c5003bee5ae1,0
scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/disk@g5000c5003bee5ae3 (sd6):
SCSI transport failed: reason 'reset': retrying command

Workaround: No work around needed. The system will retry the failed command automatically.

Contact your authorized Oracle service provider if the following message is seen:

SCSI transport failed: reason 'reset': giving up

Rebooting an SDIO-SAS HBA Guest Domain Might Generate ereport.io.pciex.pl.re (Bug ID 15718101)

When a guest domain is configured using SDIO (Static Direct I/O) and an onboard SAS2 controller (/SYS/MB/SASHBA0 or /SYS/MB/SASHBA1) eReports of type ereport.io.pciex.pl.re will be generated at the time the guest is bound and started. Similar eReports might occur intermittently when the guest domain reboots.

Workaround: If the problem persists or occurs outside of rebooting an SDIO-SAS HBA guest domain, contact your authorized Oracle Service Provider for additional assistance.

Otherwise, you can safely ignore this message.

Characters Are Occasionally Dropped at the Oracle OpenBoot Prompt (Bug ID15813690)

In some cases, input characters are dropped or doubled at the Oracle OpenBoot (ok) prompt.

Workaround: Retype the command.