Platform Notes: Ultra 450 Workstation and Ultra Enterprise 450 Server

Automatic System Recovery

The automatic system recovery (ASR) feature allows an Ultra 450 system to resume operation after experiencing certain hardware faults or failures. Power-on self-test (POST) and OpenBoot diagnostics (OBDiag) can automatically detect failed hardware components, while an auto-configuring capability designed into the OBP firmware allows the system to deconfigure failed components and restore system operation. As long as the system is capable of operating without the failed component, the ASR features will enable the system to reboot automatically, without operator intervention. Such a "degraded boot" allows the system to continue operating while a service call is generated to replace the faulty part.

If a faulty component is detected during the power-on sequence, the component is deconfigured and, if the system remains capable of functioning without it, the boot sequence continues. In a running system, certain types of failures (such as a processor failure) can cause an automatic system reset. If this happens, the ASR functionality allows the system to reboot immediately, provided that the system can function without the failed component. This prevents a faulty hardware component from keeping the entire system down or causing the system to crash again.

"Soft" Deconfiguration via Status Property

To support a degraded boot capability, the OBP uses the 1275 Client Interface (via the device tree) to "mark" devices as either failed or disabled, by creating an appropriate "status" property in the corresponding device tree node. By convention, UNIX will not activate a driver for any subsystem so marked.

Thus, as long as the failed component is electrically dormant (that is, it will not cause random bus errors or signal noise, etc.), the system can be rebooted automatically and resume operation while a service call is made.

"Hard" Deconfiguration

In two special cases of deconfiguring a subsystem (CPUs and memory), the OBP actually takes action beyond just creating an appropriate "status" property in the device tree. At the first moments after reset, the OBP must initialize and functionally configure (or bypass) these functions in order for the rest of the system to work correctly. These actions are taken based on the status of two NVRAM configuration variables, post-status and asr-status, which hold the override information supplied either from POST or via a manual user override (see "ASR User Override Capability").

CPU Deconfiguration

If any CPU is marked as having failed POST, or if a user chooses to disable a CPU, then the OBP will set the Master Disable bit of the affected CPU, which essentially turns it off as an active UPA device until the next power-on system reset.

Memory Deconfiguration

Detecting and isolating system memory problems is one of the more difficult diagnostic tasks. This problem is further complicated by the system's various modes of memory interleaving as well as the possibility of mismatching memory DIMMs within the same bank.

Given a failed memory component, the firmware will deconfigure the entire bank associated with the failure. This policy also means that the degraded configuration may mean a lower interleave factor, a less than 100 percent utilization of remaining banks, or both depending on the interleave factor.

ASR User Override Capability

While the default settings will properly configure or deconfigure an Ultra 450 system in most cases, it is useful to provide advanced users with a manual override capability. Because of the nature of "soft" versus "hard" deconfiguration, it is necessary to provide two related but different override mechanisms.

"Soft" Deconfigure Override

For any subsystem represented by a distinct device tree node, users may disable that function via the NVRAM variable asr-disable-list, which is simply a list of device tree paths separated by spaces.

ok setenv asr-disable-list /pci/ebus/ecpp /pci@1f,4000/scsi@3

The Ultra 450 OBP will use this information to created disabled status properties for each node listed in the variable asr-disable-list.

"Hard" Deconfigure Override

For overriding those subsystems that require "hard" deconfiguration (CPU and memory), the OBP commands asr-enable and asr-disable are used to selectively enable or disable each subsystem.

Note -

There are duplications between the soft and hard overrides. If possible, the hard override commands asr-enable and asr-disable should be used.

To keep track of the status of all manual overrides, a new user command, .asr, is provided to summarize the current settings.

ok asr-disable cpu1 bank3
ok .asr
CPU0:	Enabled	
CPU1:	Disabled	
CPU2:	Enabled	
CPU3:	Enabled	
SC-Marvin:	Enabled	
Psycho@1f:	Enabled	
Psycho@4:	Enabled	
Psycho@6:	Enabled	
Cheerio:	Enabled	
SCSI:	Enabled	
Mem Bank0:	Enabled	
Mem Bank1:	Enabled	
Mem Bank2:	Enabled	
Mem Bank3:	Disabled	
PROM:	Enabled	
NVRAM:	Enabled	
TTY:	Enabled	
Audio:	Enabled	
SuperIO:	Enabled	
PCI Slots:	Enabled

Auto-Boot Options

OpenBoot provides for an NVRAM controlled switch called auto-boot?, which controls whether OBP will automatically boot the operating system after each reset. The default for Sun platforms is true.

If a system fails power-on diagnostics, then auto-boot? is ignored and the system does not boot unless the user does it manually. This behavior is obviously not acceptable for a degraded boot scenario, so the Ultra 450 OBP provides a second NVRAM-controlled switch called auto-boot-on-error?. This switch controls whether the system will attempt a degraded boot when a subsystem failure is detected. Both the auto-boot? and auto-boot-on-error? switches must be set to true to enable a degraded boot.

ok setenv auto-boot-on-error? true

Note -

The default setting for auto-boot-on-error? is false. Therefore, the system will not attempt a degraded boot unless you change this setting to true. In addition, the system will not attempt a degraded boot in response to any fatal unrecoverable error, even if degraded booting is enabled. An example of a fatal unrecoverable error is when all of the system's CPUs have been disabled, either by failing POST or as a result of a manual user override.

Reset Scenarios

The standard system reset protocol bypasses firmware diagnostics completely unless the NVRAM variable diag-switch? is set to true. The default setting for this variable is false.

To support ASR in an Ultra 450 system, it is desirable to be able to run firmware diagnostics (POST/OBDiag) on any or all reset events. Rather than simply changing the default setting of diag-switch? to true, which carries with it other side effects (see the OpenBoot 3.x Command Reference Manual), the Ultra 450 OBP provides a new NVRAM variable called diag-trigger that lets you choose which reset events, if any, will automatically engage POST/OBDiag. The diag-trigger variable, and its various settings are described in the following table.

Note -

diag-trigger has no effect unless diag-switch? is set to true.

Table 2-5 Settings for power-reset, error-reset, and soft-reset


Setting	Function
`power-reset` (default)	Runs diagnostics only on power-on resets.
`error-reset`	Runs diagnostics only on power-on resets, fatal hardware errors, and watchdog reset events.
`soft-reset`	Runs diagnostics on all resets (except XIR), including resets triggered by UNIX `init` `6` or `reboot` commands.
`none`	Disables the automatic triggering of diagnostics by any reset event. Users can still invoke diagnostics manually by holding down the Stop and d keys when powering on the system, or by turning the front panel keyswitch to the Diagnostics position when powering on the system.

In the following example, the diag-trigger variable is used to trigger POST and OpenBoot diagnostics on all resets except XIR resets.

ok setenv diag-switch? true
ok setenv diag-trigger soft-reset