Sun SPARC Enterprise(R) M3000/M4000 - reset-all is canceled due to no available SCF path

Asset ID:	1-72-1607609.1
Update Date:	2018-03-05
Keywords:

Solution Type Problem Resolution Sure

Solution 1607609.1 : Sun SPARC Enterprise(R) M3000/M4000 - reset-all is canceled due to no available SCF path

Applies to:

Sun SPARC Enterprise M4000 Server - Version All Versions to All Versions [Release All Releases]
Sun SPARC Enterprise M3000 Server - Version All Versions to All Versions [Release All Releases]
All Platforms
The behavior described in this document has been seen on M3000 and M4000. It was observed after a scheduled maintenance reboot as well as after panic reboots.
This document applies only if the XSCF 'showstatus' command indicates there are "No failures found."

Symptoms

The domain fails to boot indicating "no available path." This may occur after a reboot (e.g., following an XCP upgrade).
Likewise, reset-all fails with the error indication that "reset-all is canceled due to no available SCF path."

See the below example:

rebooting...
Resetting...
SCFcmd:0x1022 ignored due to no available path
SCFcmd:0x430 ignored due to no available path
reset-all is canceled due to no available SCF path
panic - kernel: prom_reboot: reboot call returned!
SCFcmd:0x10 ignored due to no available path
SCFcmd:0x4021 ignored due to no available path
Program terminated

{1} ok reset-all
Resetting...
SCFcmd:0x1022 ignored due to no available path
SCFcmd:0x430 ignored due to no available path
reset-all is canceled due to no available SCF path

Power off/on may permit the domain to boot, but eventually WARNING messages similar to the following appear:

Boot device: disk:a File and args:
SunOS Release 5.10 Version Generic_147440-19 64-bit
Copyright (c) 1983, 2012, Oracle and/or its affiliates. All rights reserved.
OpenBoot: no available scf path
WARNING: Initial date is invalid.
Attempting to set the date and time based on the last shutdown.
The time could not be synchronized between Domain and Service Processor.
Please inspect the date and time and correct if necessary.
SCFcmd:0x260 ignored due to no available path
WARNING: Time of Day clock error: reason [Reversed by 0x1ff46b80]. -- Stopped tracking Time Of Day clock.
WARNING: Time-of-day chip unresponsive; dead batteries?

'showstatus' indicates there are no faults.

XSCF> showstatus
No failures found in System Initialization.

The firmware level is within supported range.

Cause

The behavior is caused by the temporarily unavailabile SCF to OBP domain path and was not reproducible following a platform power cycle.

The SCF path is the communication channel between the domain and the XSCF. It is implemented via IOSRAM existing on the IOU. Upon
path failure, the XSCF should select another available path if one is available. The M3000 and the M4000 configured in uni-mode have only
one IOSRAM path and consequently there are no alternate paths available.

Assumtion is also, that all potential BUGs related to TOD are already fixed in the given Solaris configuration,
and therefor the behavior may not reproducible in term of the Solaris WARNINGs.

With the above given symptoms there is no hardware fault and no hardware should be replaced. The Time-Of-Day chip and the battery
warnings are misleading and do not indicate any hardware is faulty. The WARNING messages are a consequence of the failed
communication between OBP and the SCF.

Solution

Power cycle the platform to reinitialize all hardware, including the XSCF, by following these steps:

Verify how many domains are affected by a platform power cycle:

XSCF> showdomainstatus -a

Shutdown each Solaris instance running on the server

# init 0

It is recommended to check the issue is resolved after the power cycle before starting the Solaris instance.
This may be accomplished by setting the auto-boot environment in OBP to false.

ok> setenv auto-boot? false
auto-boot = false

Then power off all the domains

XSCF> poweroff -a

To power cycle the platform all AC power cords must be removed.
After a complete chassis power cycle make certain to allow a minimum of 30 seconds
before connecting the power cords back into the chassis.

When the system is available after the power cycle, the above mentioned symptoms should no
longer occur and Solaris should boot without indication of an unreachable TOD chip.

To discuss this information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in an appropriate
My Oracle Support Community - Oracle Sun Technologies Community.

Attachments

This solution has no attachment