Why Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000 (OPL) domain not responding to sendbreak, unable to force a kernel crash dump?

Asset ID:	1-72-1393137.1
Update Date:	2012-01-18
Keywords:

Solution Type Problem Resolution Sure

Solution 1393137.1 : Why Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000 (OPL) domain not responding to sendbreak, unable to force a kernel crash dump?

Related Items


Sun SPARC Enterprise M9000-64 Server
 Sun SPARC Enterprise M9000-32 Server
 Sun SPARC Enterprise M8000 Server
 Sun SPARC Enterprise M4000 Server
 Sun SPARC Enterprise M5000 Server
 Sun SPARC Enterprise M3000 Server
 Solaris SPARC Operating System

Related Categories


PLA-Support>Sun Systems>SPARC>Enterprise>SN-SPARC: Mx000
 .Old GCS Categories>Sun Microsystems>Servers>OPL Servers

There were many occasions that when a M-series domain hang, an attempt to 'sendbreak' to the domain from XSCF did not result in the domain dropping into the  prompt. This is mostly attributed to the fact the domain secure mode is set to "on"

In this Document
  Symptoms
  Cause
  Solution
  References

Created from <SR 3-5129697580>

Applies to:

Sun SPARC Enterprise M4000 Server - Version: Not Applicable and later   [Release: N/A and later ]
Sun SPARC Enterprise M5000 Server - Version: Not Applicable and later    [Release: N/A and later]
Sun SPARC Enterprise M3000 Server - Version: Not Applicable and later    [Release: N/A and later]
Solaris SPARC Operating System - Version: 10 3/05 and later    [Release: 10.0 and later]
Sun SPARC Enterprise M8000 Server - Version: Not Applicable and later    [Release: N/A and later]
Oracle Solaris on SPARC (64-bit)
Hang, force kernel crash dump, ok prompt, OPL

Symptoms

After a 'sendbreak -d DID' to a domain, connecting back to the console shows that the system did not drop into 'ok' prompt:

XSCF> sendbreak -d 0
Send break signal to DomainID 0?[y|n] :y
XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y

m3000-dom00 console login:

Cause

The common reason for such observation is that the domain is in secure mode (which is the default). Under secure mode, 'sendbreak' is ignored.

The secure mode of the domain can be verified by using the 'showdomainmode -d DID' XSCF command:

XSCF> showdomainmode -d 0
Host-ID             :84ee0ebe
Diagnostic Level    :min
Secure Mode         :on        <<------ secure mode on
Autoboot            :on 
CPU Mode            :auto

Solution

For the purpose of forcing a Solaris kernel crash dump, changing the Secure Mode of the domain is not necessary. The use of XSCF command 'reset -d DID panic' gives us a similar result and generates a coredump.

The reset panic sub-command will panic the system regardless of the Secure Mode of the domain.

XSCF> reset -d 0 panic
DomainID to panic:00
Continue? [y|n] :y
00 :Panicked

*Note*
 This command only issues the instruction to reset.
 The result of the instruction can be checked by the "showlogs power".
XSCF> console -d 0 -y
Connect to DomainID 0?[y|n] :y
 0:17 100% done
100% done: 86836 pages dumped, dump succeeded
rebooting...
Resetting...

For further details regarding Secure Mode, sendbreak and various other options in dealing with system hang on the M-series machines, please refer to Document 1020078.1 Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000 (OPL) Servers: How to deal with a hung or unresponsive domain.

References

<NOTE:1008229.1> - Gathering diagnostic data for SPARC Enterprise M3000/M4000/M5000/M8000/M9000 (OPL) Servers
<NOTE:1020078.1> - Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000 (OPL) Servers: How to deal with a hung or unresponsive domain ?

Attachments

This solution has no attachment