SPARC T5-2
 

PLA-Support>Sun Systems>SPARC>CMT>SN-SPARC: T5
 

In this Document

Symptoms

Cause

Solution

References

Oracle Confidential PARTNER - Available to partners (SUN).
Reason: Analysis requires platform specific knowledge
Created from <SR 3-15915213121>

Applies to:

Symptoms

SPARC T5-2 powered down and reported FMA fault SPT-8000-J4

FMA Fault

2017-10-11/15:42:04  ereport.component.absent@/SYS/SASBP
                         detector = /SYS/SASBP/PRSNT
                         hidden   = true

Service Processor event logs

315    Wed Oct 11 15:42:04 2017  Chassis   Action    major
       Hot removal of /SYS/SASBP
       
316    Wed Oct 11 15:42:04 2017  Power     Off       major
       Power to /SYS has been turned off by: SP, Reason: Fault

Cause

ereport.component.absent events occur when the system loses the ability to access a component over the i2c communication interface. This can be a result of the indicted device suffering a failure, or one of the devices that share the same i2c bus could fail in a way to essentially lock the entire segment.

As a result the implicated device may not be the cause of the fault and further diagnosis may be required to better isolate root cause.
 
The i2c interconnect is a two wire communication bus where multiple devices act as slaves responding to requests from a single master device. In most cases loss of communication is indicative of the reporting device suffering a fault, however in some circumstances it may be a victim where another component is causing the i2c bus to hang and as a result prevents other all devices from responding to requests.
 

Solution

Initial testing should be to verify communication over the various i2c segments.

Log into the restricted shell on the Service Processor;

Run i2ctest to verify which devices are responding to requests;

If multiple devices are impacted it is possible we have a single component failure preventing communication to all devices that share the same i2c segment. In this scenario please engage a backline engineer to assist with confirming which bus(es) are impacted, and to confirm next steps.

Where we have multiple potential suspect devices it is invariably necessary to reduce the system configuration to better narrow down the offending device. In this example it was necessary to remove various components one at a time until root cause was isolated to the Fan Board; even though the fault was reported against the SASBP both components share the same i2c segment.

Minimum configuration testing identified the Fan Board as the faulty component which was causing the entire i2c_chassis bus to hang. The board was returned for CPAS testing and Oracle engineering verified it had extensive creep corrosion which in turn impacted i2c communication.
 

References

This solution has no attachment