Stage Two: Openboot Diagnostics Tests - Sun Microsystems Sun Fire V440 Diagnostics And Troubleshooting Manual

Bypassing diagnostic tests can create a situation where a server with faulty hardware
gets locked into a cycle of repeated booting and crashing. Depending on the type of
problem, the cycle may repeat intermittently. Because diagnostic tests are never
invoked, the crashes may occur without leaving behind any log entries or
meaningful console messages.
The section "How to Put the System in Diagnostics Mode" on page 57 provides
instructions for ensuring that your server runs diagnostics when starting up. The
section "How to Bypass Firmware Diagnostics" on page 58 explains how to disable
firmware diagnostics.
Temporarily Bypassing Diagnostics
Even if you set up the server to run diagnostic tests automatically on reboot, it is still
possible to bypass diagnostic tests for a single boot cycle. This can be useful in cases
where you are reconfiguring the server, or on those rare occasions when POST or
OpenBoot Diagnostics tests themselves stall or "hang," leaving the server unable to
boot and in an unusable state. These "hangs" most commonly result from firmware
corruption of some sort, especially of having flashed an incompatible firmware
image into the server's PROMs.
If you do find yourself needing to skip diagnostic tests for a single boot cycle, the
ALOM system controller provides a convenient way to do this. See "How to Bypass
Diagnostics Temporarily" on page 59 for instructions.
Maximizing Reliability
By default, diagnostics do not run following a user- or operating system-initiated
reset. This means the system does not run diagnostics in the event of an operating
system panic. To ensure the maximum reliability, especially for automatic system
recovery (ASR), you can configure the system to run its firmware-based diagnostic
tests following all resets. For instructions, see "How to Maximize Diagnostic
Testing" on page 61.

Stage Two: OpenBoot Diagnostics Tests

Once POST diagnostics have finished running, POST marks the status of any faulty
device as "FAILED," and returns control to OpenBoot firmware.
OpenBoot firmware compiles a hierarchical "census" of all devices in the system.
This census is called a device tree. Though different for every system configuration,
the device tree generally includes both built-in system components and optional PCI
bus devices. The device tree does not include any components marked as "FAILED"
by POST diagnostics.
Chapter 2 Diagnostics and the Boot Process 15