This chapter describes the NVRAM configuration variables and OpenBoot PROM (OBP) commands available for configuring the following aspects of Sun Enterprise 250 system behavior:
NVRAM configuration variables covered in this chapter include:
upa-port-skip-list
pci0-probe-list
pci-slot-skip-list
env-monitor
asr-disable-list
auto-boot-on-error?
diag-trigger
OBP commands covered in this chapter include:
asr-enable
asr-disable
.asr
Sun Enterprise 250 servers, like all UltraSPARC(TM)-based systems, are based on the high-speed Ultra Port Architecture (UPA) bus, a switched system bus that provides up to 32 port ID addresses (or slots) for high-speed motherboard devices like CPUs, I/O bridges, and frame buffers. The Enterprise 250 server provides up to three active ports for the following subsystems.
Table 1-1 UPA System Bus Ports
Device Type |
UPA Slot |
Physical Implementation |
---|---|---|
CPU |
0-1 |
Two plug-in slots |
UPA-PCI bridge |
1f |
Soldered on motherboard |
The order of probing these three port IDs is not subject to user control; however, a list of ports can be excluded from probing via the upa-port-skip-list NVRAM variable. In the following example, the upa-port-skip-list variable is used to exclude CPU-1 from the UPA probe list.
ok setenv upa-port-skip-list 1
This capability lets you exclude a given device from probing (and subsequent use) by the system without physically removing the plug-in card. This can be useful in helping to isolate a failing card in a system experiencing transient failures.
Of the Enterprise 250 server's two PCI buses, Bus 0 (/pci@1f,4000 in the device tree) is unique in that it is the only PCI bus that contains motherboard (non plug-in) devices such as the on-board SCSI controller. By definition, such devices cannot be unplugged and swapped to change the order in which they are probed. To control the probing order of these devices, the system provides the NVRAM variable pci0-probe-list. This variable controls both the probing order and exclusion of devices on PCI Bus 0. The values that you can specify in the pci0-probe-list are defined in the following table.
Table 1-2 Probe Values
PCI Device Number |
Function |
---|---|
2 |
PCI slot 2 (as labeled on system rear panel) |
3 |
On-board SCSI controller for internal and external SCSI devices |
4 |
PCI slot 1 (as labeled on system rear panel) |
5 |
PCI slot 0 (as labeled on system rear panel) |
The values in this list are based on the PCI device number and do not refer to the back panel slot numbering scheme of 0-3.
In the following example, the pci0-probe-list variable is used to define a probing order of 5-2-4, while excluding from the probe list the on-board SCSI controller for internal and external SCSI devices.
ok setenv pci0-probe-list 5,2,4
Note that the pci0-probe-list variable has no effect on probing of the top PCI slot (slot 3 on the system rear panel). However, another NVRAM variable, pci-slot-skip-list, is available for excluding any PCI slot from the PCI probe list. In the following example, the pci-slot-skip-list variable is used to exclude back panel slots 0 and 3 from the PCI probe list.
ok setenv pci-slot-skip-list 0,3
The values in the pci-slot-skip-list correspond to the back panel numbering scheme of 0-3. If a PCI slot number appears in this list, it will be excluded from probing even if it appears in the pci0-probe-list variable.
Environmental monitoring and control capabilities for Enterprise 250 servers reside at both the operating system level and the OBP firmware level. This ensures that monitoring capabilities are operational even if the system has halted or is unable to boot. The way in which OBP monitors and reacts to environmental over temperature conditions is controlled by the NVRAM variable env-monitor. The following table shows the various settings for this variable and the effect each setting has on OBP behavior. For additional information about the system's environmental monitoring capabilities, see "About Reliability, Availability, and Serviceability Features" in the Sun Enterprise 250 Server Owner's Guide.
Table 1-3 Environmental Monitor Values and Effects
Setting |
Monitor Active? |
Action Taken |
---|---|---|
enabled (default) |
Yes |
In response to a critical over temperature condition, OBP issues a warning and automatically shuts down the system after 30 seconds. |
advise |
Yes |
OBP issues a warning only, without shutting down the system. |
disabled |
No |
OBP takes no action at all; environmental monitoring at the OBP level is disabled. |
In the following example, the env-monitor variable is used to disable environmental monitoring at the OBP level.
ok setenv env-monitor disabled
This NVRAM variable does not affect the system's environmental monitoring and control capabilities while the operating system is running.
The automatic system recovery (ASR) feature allows Enterprise 250 servers 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.
To support a degraded boot capability, the OBP uses the IEEE 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.
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").
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.
Detecting and isolating system memory problems is one of the more difficult diagnostic tasks. This problem is further complicated by the possibility of installing different capacity DIMMs within the same memory bank. (Each memory bank must contain four DIMMs of the same capacity.) Given a failed memory component, the firmware will deconfigure the entire bank associated with the failure.
While the default settings will properly configure or deconfigure the server 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.
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@1f,2000 /pci@1f,4000/scsi@3,1
The Enterprise 250 OBP will use this information to created disabled status properties for each node listed in the variable asr-disable-list.
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.
There are duplications between the soft and hard overrides. If possible, the hard override commands asr-enable and asr-disable should be used.
You can generate a list of valid parameters for asr-disable and asr-enable by issuing either command without parameters.
ok asr-disable ? Invalid subsystem name: Known 'enable/disable' subsystem components are: bank* bank3 bank2 bank1 bank0 dimm15 dimm14 dimm13 dimm12 dimm11 dimm10 dimm9 dimm8 dimm7 dimm6 dimm5 dimm4 dimm3 dimm2 dimm1 dimm0 cpu* cpu1 cpu0 ok
To track 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 SC-MP: Enabled Psycho@1f: Enabled Cheerio: Enabled SCSI: Enabled Mem Bank0: Enabled Mem Bank1: Enabled Mem Bank2: Enabled Mem Bank3: Disabled PROM: Enabled NVRAM: Enabled TTY: Enabled SuperIO: Enabled PCI Slots: Enabled
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 Enterprise 250 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
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 both of the system's CPUs have been disabled, either by failing POST or as a result of a manual user override.
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 Enterprise 250 servers, 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 Enterprise 250 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.
diag-trigger has no effect unless diag-switch? is set to true.
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