Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-79-2264013.1
Update Date:2017-10-17
Keywords:

Solution Type  Predictive Self-Healing Sure

Solution  2264013.1 :   M12-upset_domain.keep-alive - Solaris panics but the reason is unknown to XSCF software  


Related Items
  • Fujitsu SPARC M12-1
  •  
  • Fujitsu SPARC M12-2
  •  
  • Fujitsu SPARC M12-2S
  •  
Related Categories
  • PLA-Support>Sun Systems>Sun_Other>Sun Collections>SN-OTH: Sun PSH
  •  




In this Document
Purpose
Details
References


Applies to:

Fujitsu SPARC M12-2
Fujitsu SPARC M12-2S
Fujitsu SPARC M12-1
SPARC

Purpose

Provide additional information for message ID: M12-upset_domain.keep-alive

Fujitsu fault codes:
01B90000, 01B90002, 01B90003, 01B90004, 01BA0000, 01BA0002,
01BA0003, 01BA0004, 01BA0008

Details

Type

Software  

  upset_domain.keep-alive

Severity

Major

Description

Upset due to the XSCF timeout of the keep alive handshake between domain software (POST, OBP or Solaris) and XSCF.  The reason for the  timeout is unknown by the XSCF software.

Automated Response

XSCF initiate reset, then poweroff. The administrator should look at the domain's console to identify the cause of the timeout.

Impact

Nothing will be deconfigured.

Indicted Hardware

No FRU will be specified for replacement. The PPAR ID will be displayed within the logged message.

 

Suggested Action for System Administrator

The system administrator should examine output displayed to the XSCF console, domain's console, domain logs files (/var/adm/messages, fmdump -v) and the output from the following XSCF commands (showstatus, showhardconf, showlogs error ) to gain a further understanding of the problem.

If there is no explanation why the domain panic'ed, then proceed with the steps outlined below.

  1. Collect diagnostics data:
    • In most cases a snapshot from the main XSCFU will be required to quickly and accurately identify the issue.  See Document 2097446.1 - SPARC Mx000 and M10/M12 systems: Simple Instructions to Collect an XCP Snapshot
    • In the event of a software panic and some hardware panics a domain explorer will also be needed.
    • Corefiles generated from the panic should be saved and may need to be uploaded ( See Document 1020199.1 ).
  2. Gather the snapshot and explorer data bundles and contact your Authorized Service Provider.
    • See Document 1010911.1 - What Should I Send to Oracle After a Solaris Panic or Unexpected Reboot?

Refer to the following document for the latest procedures for displaying event content in preparation for submitting a service request and applying any post-repair actions that may be required.

PSH Procedural Article for Fujitsu M10 Diagnosis (Doc ID 1525156.1)

References

<NOTE:1010911.1> - What Should I Send to Oracle After a Solaris Panic or Unexpected Reboot?
<NOTE:1540225.1> - Data Collection for Fujitsu M10/M12 Servers
<NOTE:1020199.1> - How to Upload Support Files to Oracle Such as Explorer and Crash Dumps
<NOTE:2097446.1> - SRDC – SPARC Mx000 and M10/M12 systems: Simple Instructions to Collect an XCP Snapshot

Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback