Skip Navigation Links | |
Exit Print View | |
Oracle® x86 Servers Diagnostics Guide For Servers Supporting Oracle ILOM 3.0.x |
1. Introduction to Diagnostic Tools
Diagnostic Tools for Oracle Servers
Oracle VTS Bootable Diagnostics CD
Using the Diagnostic Tools to Troubleshoot a Server
Setting Up a Server for Testing
2. U-Boot Diagnostic Start-Up Tests
U-Boot Diagnostic Start-Up Tests Overview
Server Diagnostic Test Options at Start-Up
U-Boot Diagnostic Test Modes - Normal, Quick, and Extended
Reporting of Diagnostic Failures at Server Start-Up
Running the U-Boot Diagnostic Tests
To Select a U-Boot Diagnostic Mode to Run at Start-Up
U-Boot Normal Mode - Test Output Sample
U-Boot Quick Mode - Test Output Sample
U-Boot Extended Mode - Test Output Sample
Sample SP Environmental Variables Showing U-Boot Test Status
3. Pc-Check Diagnostics Utility
Accessing the Pc-Check Diagnostics Utility
To Access Pc-Check Using the Oracle ILOM Web Interface
To Access Pc-Check Using the Oracle ILOM CLI
System Information Menu Options
Advanced Diagnostics Tests Menu Options
Immediate Burn-in Testing Menu Options
To Create and Save Scripts for Deferred Burn-in Testing
This section provides different strategies for diagnostics. This section contains the following topics:
To be effective, troubleshooting and diagnoses must be systematic and progressive. Therefore, follow these steps when diagnosing server problems:
For more information about each element of this approach, see the following topics:
The Oracle Integrated Lights Out Manager (Oracle ILOM) SP uses Linux. The first code executed by the SP is a small boot loader known as U-Boot. The U-Boot code performs similar functions to the BIOS power-on self test (POST) in that it initializes devices, with minimal testing, and boots the Linux kernel.
Diagnostics that are performed before the operating system (OS) is booted can assume complete control of a subsystem or system’s resources. These diagnostics support the most thorough testing of components, since the diagnostics control all of the resources under test. However, the effort to write the code to manage all resources under test, while providing fine-grained control, can be quite complex (effectively a light-weight OS tailored to testing). To avoid development of such complex infrastructure, pre-OS diagnostics might provide thorough, targeted testing of components in isolation.
Standalone diagnostics are typically run in manufacturing environments or at a customer site during a new server installation. In this environment, the diagnostics can be run without being concerned about corrupting or destroying customer data. Standalone diagnostics are run with the assumption that there are no restrictions on resource utilization (for example, they can force CPU and/or IO boundary conditions to achieve effective testing) since the servers are not in use by customers.
When diagnostics are written on top of an operating system, the diagnostics can rely on the resources of the OS (for example, process scheduling) to allow simultaneous testing of multiple components. However, some direct control of the components might be lost. That is, the OS will, as necessary, enforce encapsulation of hardware resources to prevent access by the diagnostics to ensure reliable server behavior.
Further, since the OS inherently manages server resources, exercises can be built using the OS that can test multiple subsystems simultaneously.
Online OS diagnostics are similar to offline OS diagnostics in terms of support of resources. However, online diagnostics are run in customer sites and cannot alter data repositories and must be careful not to over utilize server resources (for example, these diagnostics must not consume too many CPU cycles or too much network bandwidth).
Note - Oracle does not expect that customers will run online OS diagnostics since those diagnostics drain compute resources and have limited effectiveness due to their inability to lock resources. The Fault Management Architecture eliminates the need for online diagnostics.