SPARC M6-32
 
SPARC M5-32
 

PLA-Support>Sun Systems>SPARC>Enterprise>SN-SPARC: Mx-32
 

In this Document

Symptoms

Cause

Solution

Oracle Confidential PARTNER - Available to partners (SUN).
Reason: diagnosis should be made by service delivery partner or Oracle
Created from <SR 3-13206886452>

Applies to:

Symptoms

The FMA diagnosis of code SPT-8000-1Q for an indicted SPPx might be a misdiagnosis.

- fmadm faulty shows the following example output with the indictment of an SPP as suspect:
2016-08-19/13:04:49 7a230cbd-9484-4290-dce2-d6e063b7e9ee SPT-8000-1Q Critical

Problem Status : open
Diag Engine : fdd 1.0
System
Manufacturer : Oracle Corporation
Name : SPARC M6-32
Part_Number : 33137606+1+1
Serial_Number : AK00290000

----------------------------------------
Suspect 1 of 1
Fault class : fault.chassis.device.fail
Certainty : 100%
Affects : /SYS/SPP2
Status : faulted

FRU
Status : faulty
Location : /SYS/SPP2
Manufacturer : Celestica Holdings PTE LTD
Name : Assy SP Proxy
Part_Number : 7075727
Revision : 01
Serial_Number : 465769T+1334WF02GA
Chassis
Manufacturer : Oracle Corporation
Name : SPARC M6-32
Part_Number : 33137606+1+1
Serial_Number : AK00290000

Description : A device necessary to support a configuration has failed.

Response : The service required LED on the chassis will be illuminated.

Impact : The chassis may be powered down.

Action : Please refer to the associated reference document at
http://support.oracle.com/msg/SPT-8000-1Q for the latest
service procedures and policies regarding this diagnosis.

- The SPPx was restarted to cause the fault:

957 Fri Aug 19 13:04:49 2016 Fault Fault critical Fault detected at time = Fri Aug 19 13:04:49 2016. The suspect component: /SYS/SPP2 has fault.chassis.device.f
ail with probability=100. Refer to http://support.oracle.com/msg/SPT-8000-1Q for details.
956 Fri Aug 19 12:58:04 2016 Power On major Power to /SYS/SPP2 has been turned on by: Shell session, Username:root
955 Fri Aug 19 12:38:56 2016 Power Off major Power to /SYS/SPP2 has been turned off by: Shell session, Username:root

- The ereports generated during the event include:

2016-08-19/13:04:48 ereport.chassis.post.dev.test-fail@/SYS/SPP2
IPOSTReport = ERROR
detector = /SYS/SPP2/GPIO2
TestTitle = iPOST PCA9555 I2C Read/Write Test
Operation = Polarity Inversion Port 0 Register Read
SlaveAddr = 0x32
RegAddr = 0x04
ReportEnd = ReportEnd

2016-08-19/13:04:50 ereport.chassis.device.fail@/SYS/IOU2/IOB1
[unrecognized]
detected-by = POD
component_name = /SYS/IOU2/IOB1/GPIO0

2016-08-19/13:04:50 ereport.chassis.device.fail@/SYS/IOU2/IOB1
[unrecognized]
detected-by = POD
component_name = /SYS/IOU2/IOB1/GPIO5

2016-08-19/13:04:50 ereport.chassis.device.fail@/SYS/SPP2
[unrecognized]
detected-by = POD
component_name = /SYS/SPP2/GPIO2

2016-08-19/13:05:04 ereport.chassis.sp.restart@/SYS/SPP2
Reset reason = power-on

Cause

The root cause might be a failed IOBx board within the IOU that the SPP manages.

Collect show /SYS/IOUx output to make certain all expected devices are listed.

For example, in this case IOB0 is missing.

-> show /SYS/IOU2

/SYS/IOU2
Targets:
EMS3
EMS4
HDDBP1
IOB1 <<<< IOB1 is listed, but not IOB0
PCIE9
PCIE10
PCIE11
PCIE12
PCIE13
PCIE14
PCIE15
PCIE16

Properties:
type = I/O Unit

 This problem is documented in bug 24750944

Solution

Make certain all expected devices under the IOUx target are listed.  Check for any missing components.

For example, show target output of IOU2 demonstrates that IOB0 is missing, which was the root cause of the SPPx getting improperly faulted when the SPPx is started.

-> show /SYS/IOU2

/SYS/IOU2
Targets:
EMS3
EMS4
HDDBP1
IOB1 <<<< IOB1 is listed, but not IOB0
PCIE9
PCIE10
PCIE11
PCIE12
PCIE13
PCIE14
PCIE15
PCIE16

Properties:
type = I/O Unit

Corrective action is to replace the unlisted (missing) component. In the above example, replacing the /SYS/IOU2/IOB0 resolved the issue.

This solution has no attachment