You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4169 lines
192 KiB
XML
4169 lines
192 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Copyright (c) 2016, 2020 OpenPOWER Foundation
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
you may not use this file except in compliance with the License.
|
|
You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
|
|
-->
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xl="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:lang="en"
|
|
xml:id="dbdoclet.50569347_31867">
|
|
<title>Service Indicators</title>
|
|
|
|
<para>This chapter defines service indicators
|
|
<footnote xml:id="pgfId-648393">
|
|
<para>Note that many times “indicators” are referred to as
|
|
“LEDs” as this is one of the most common implementations for
|
|
indicators at the current time.</para>
|
|
</footnote>relative to:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Which service indicators may be exposed to an OS and which may
|
|
not</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The usage model for service indicators, regardless of whether they
|
|
are exposed to the OS or not</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<section xml:id="dbdoclet.50569347_15739">
|
|
<title>General</title>
|
|
<para>This section gives some general background information required to
|
|
understand the service indicator requirements. The service indicator
|
|
requirements can be found starting in
|
|
<xref linkend="dbdoclet.50569347_24150" />.</para>
|
|
|
|
<section xml:id="dbdoclet.50569347_67030">
|
|
<title>Basic Platform Definitions</title>
|
|
<para>The following are the definitions of some of the terms used in this
|
|
architecture. See also
|
|
<xref linkend="dbdoclet.50569388_37308"/> for additional terms.</para>
|
|
|
|
<section xml:id="dbdoclet.50569347_12130">
|
|
<title>“Enclosure”, Packaging, and Other
|
|
Terminology</title>
|
|
<para>In order to abstract specific packaging differences between
|
|
different products, this architecture uses a number of terms that denote
|
|
a unit of packaging.</para>
|
|
<para>The term
|
|
<emphasis>enclosure</emphasis> means something different, depending on the
|
|
product line. Generally this is an entity that can be unplugged and be
|
|
removed from the system, but may include the entire system, and generally
|
|
encloses other FRUs. It is, however, possible to have a FRU that contains
|
|
|
|
<emphasis>one</emphasis> other FRU, and not have it be an enclosure. See
|
|
below, for more information.</para>
|
|
<para>The concept of the enclosure is very key to this architecture,
|
|
because the enclosure provides the anchor point for the Enclosure Fault,
|
|
Enclosure Identify, and (when applicable) the Error Log indicators.
|
|
<emphasis></emphasis></para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>For a blade system, a base blade plus any attached
|
|
sidecars.</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A <emphasis>sidecar</emphasis> is a blade that plugs
|
|
into a blade slot, but
|
|
which is physically connected to the base blade and which cannot be
|
|
removed without also removing the base blade and any other attached
|
|
sidecars.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Enclosure Identify indicator is located on the base blade.
|
|
Sidecars do not have an Enclosure Identify indicator.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A stand-alone computing box, like a deskside unit.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A separately powered box that attaches to a stand-alone computing
|
|
box (for example, an I/O expansion tower).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For a rack system, a drawer or partial drawer, with its own power
|
|
domains, within a rack system (but not a chassis, in blade system
|
|
terms).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>FRUs that have one or no internal FRUs are a possible exception to
|
|
the above definition of enclosure. The general requirements are that the
|
|
enclosing FRU does not need an Error Log indicator (see also Requirement
|
|
<xref linkend="dbdoclet.50569347_86824" />), implements the full xipSIA
|
|
Lightpath architecture
|
|
<emphasis>including FRU Identify</emphasis>, has the enclosing FRU
|
|
Fault/Identify and internal (if any) FRU Fault/Identify indicators
|
|
visible from the outside of the system the same way that enclosure
|
|
indicators would be, and rolls-up the FRU Fault/Identify indicators to
|
|
the next level of indicators when there is a next level (for example,
|
|
chassis level indicators). Examples of the type of FRUs that the xipSIA
|
|
architecture team
|
|
<emphasis>might</emphasis> approve as a non-enclosures is:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Appliance drawers (“appliance” means that there are
|
|
no field serviceable parts inside).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Appliance Blades, except if they require an Error Log
|
|
indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A power supply which comprises two or fewer FRUs.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fans, but not fan assemblies when the fan assemblies have three
|
|
or more Fault indicators.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>In addition, the term
|
|
<emphasis>System Enclosure</emphasis> (also known as a
|
|
<emphasis>Primary Enclosure</emphasis>) is used to denote the enclosure
|
|
of a system that contains the one and only Error Log indicator
|
|
<footnote xml:id="pgfId-667292">
|
|
<para>Previously known as the System Information (Attention)
|
|
indicator.</para>
|
|
</footnote>for the system. An enclosure that is not a System Enclosure is
|
|
called a
|
|
<emphasis>secondary enclosure</emphasis>. The System Enclosure is
|
|
expected to be one that contains at least some of the system processors
|
|
for the platform.</para>
|
|
|
|
<para>In this chapter, the term
|
|
<emphasis>chassis</emphasis> will refer to a blade system chassis.</para>
|
|
|
|
<para>Other terminology used in this chapter includes:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">activate</emphasis></term>
|
|
<listitem>
|
|
<para>To activate an indicator (physical or virtual) means to
|
|
set it to a non-off state (blink, blip, or on). An indicator does not
|
|
need to be in the off (deactivated) state prior to being activated (for
|
|
example a second request to activate an already active indicator, is also
|
|
considered to be an activation of that indicator).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">active state</emphasis></term>
|
|
<listitem>
|
|
<para>An indicator in an active state is in a non-off state.
|
|
Different indicator types can be set to a different set of active states.
|
|
For each of the following indicators, the following states are applicable
|
|
in the indicator active state (See
|
|
<xref linkend="dbdoclet.50569347_69815" /> for more detail on when each
|
|
state is applicable and for the conditions under which a state transition
|
|
is made):</para>
|
|
<para>FRU Identify: blink</para>
|
|
<para>FRU Fault: on</para>
|
|
<para>Blue Enclosure Identify: on or blink</para>
|
|
<para>Enclosure Fault: on or blip</para>
|
|
<para>Error Log: on</para>
|
|
<para>Blue Rack Identify: on</para>
|
|
<para>Blue Row Identify: on</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">blip</emphasis></term>
|
|
<listitem>
|
|
<para>A blink state with a short duty cycle used in the
|
|
“remind” state for Enclosure Fault Indicators. See also
|
|
Requirement
|
|
<xref linkend="dbdoclet.50569347_55538" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Chassis Enclosure Identify</emphasis></term>
|
|
<listitem>
|
|
<para>An Enclosure Identify indicator at the blade system chassis
|
|
level.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">CRU</emphasis></term>
|
|
<listitem>
|
|
<para>See FRU.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">deactivate</emphasis></term>
|
|
<listitem>
|
|
<para>To deactivate an indicator (physical or virtual) means
|
|
to set it to the off state. Deactivating a virtual indicator may or may
|
|
not deactivate the physical indicator associated with that virtual
|
|
indicator (see
|
|
<xref linkend="dbdoclet.50569347_69815" />).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Enclosure Fault</emphasis></term>
|
|
<listitem>
|
|
<para>An amber indicator which indicates, when activated,
|
|
that there is a FRU Fault indicator in the enclosure that is
|
|
active.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Enclosure Identify</emphasis></term>
|
|
<listitem>
|
|
<para>An indicator that is used to identify an
|
|
enclosure in an installation or an enclosure in a group. This indicator
|
|
is blue in color and is turned on in the active identify state.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FRU</emphasis></term>
|
|
<listitem>
|
|
<para>Field Replaceable Unit. Used to also mean CRU (Customer
|
|
Replaceable Unit) in this chapter.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FRU Fault</emphasis></term>
|
|
<listitem>
|
|
<para>An amber indicator that is used to point to a failing FRU
|
|
in an enclosure.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">FRU Identify</emphasis></term>
|
|
<listitem>
|
|
<para>An amber indicator that is used to identify a FRU in
|
|
an enclosure or a place where a FRU is to be plugged (for example, for an
|
|
upgrade operation).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Guiding Light Mode</emphasis></term>
|
|
<listitem>
|
|
<para>A platform implementation that provides FRU
|
|
Identify indicators for identifying failing FRUs. See
|
|
<xref linkend="dbdoclet.50569347_16804" /> for more information.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">ID</emphasis></term>
|
|
<listitem>
|
|
<para>Shorthand used some places (mainly figures) in this chapter for
|
|
“Identify” or “Identify indicator”.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Lightpath Mode</emphasis></term>
|
|
<listitem>
|
|
<para>A platform implementation that provides FRU Fault
|
|
indicators as the general way to identify failing FRUs. See
|
|
<xref linkend="dbdoclet.50569347_16804" /> for more information.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">not visible to the OS</emphasis></term>
|
|
<listitem>
|
|
<para>See transparent to the OS.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">primary level indicators</emphasis></term>
|
|
<listitem>
|
|
<para>The enclosure level indicators. For
|
|
example, for rack systems, the enclosure is either the blade, for blade
|
|
systems, or the drawer level, for non-blade systems.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">roll-down</emphasis></term>
|
|
<listitem>
|
|
<para>This term is not used by this architecture, but some
|
|
people refer to roll-up as the action of activating a higher level
|
|
indicator and roll-down as the action of deactivating a lower level
|
|
indicator. This architecture will use roll-up for both activation and
|
|
deactivation. See roll-up.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">roll-up</emphasis></term>
|
|
<listitem>
|
|
<para>The action of activating a higher level indicator, when a
|
|
lower level indicator is activated, and deactivating it when all the
|
|
lower level indicators that roll-up to that indicator are deactivated.
|
|
For example, if a FRU Fault indicator is activated, it rolls-up and turns
|
|
on the Enclosure Fault indicator, and when the last FRU Fault indicator
|
|
in an enclosure is deactivated, the Enclosure Fault indicator for that
|
|
enclosure is deactivated.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">secondary level indicators</emphasis></term>
|
|
<listitem>
|
|
<para>The indicators on levels below the Primary Level and above the FRU
|
|
level.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">SFP</emphasis></term>
|
|
<listitem>
|
|
<para>Service Focal Point. See also
|
|
<xref linkend="dbdoclet.50569347_95432" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">Error Log</emphasis></term>
|
|
<listitem>
|
|
<para>An amber indicator that indicates that the user needs to look at
|
|
the error log or problem determination procedures, in order to determine
|
|
the cause.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">tertiary level indicators</emphasis></term>
|
|
<listitem>
|
|
<para>The FRU level indicators.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">transparent to the OS</emphasis></term>
|
|
<listitem>
|
|
<para>Indicators whose state cannot be modified or
|
|
sensed by OS or application level software. For example, power supply
|
|
Fault indicators.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">turn off</emphasis></term>
|
|
<listitem>
|
|
<para>To turn off a physical indicator means exactly like it
|
|
sounds. Turning off a virtual or logical indicator may or may not turn
|
|
off the physical indicator, depending on the state diagram for the
|
|
physical one (see
|
|
<xref linkend="dbdoclet.50569347_69815" />).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">visible to the OS</emphasis></term>
|
|
<listitem>
|
|
<para>Indicators whose state can be modified or sensed
|
|
by OS or application level software. For PCI Hot Plug indicators. See
|
|
also <xref linkend="dbdoclet.50569347_63097" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_63097">
|
|
<title>Service Indicator Visibility and Transparency to the
|
|
OS</title>
|
|
<para>An indicator is said to be transparent or not visible to the OS
|
|
when its state cannot be modified or sensed by OS or application level
|
|
software (for example, power supply Fault indicators). An indicator is
|
|
said to be visible to the OS when its state can be modified and sensed by
|
|
OS or application level software (for example, PCI Hot Plug
|
|
indicators).</para>
|
|
<para>Requirements on visibility can be found in
|
|
<xref linkend="dbdoclet.50569347_24150" />.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Service Indicator</title>
|
|
<para>A
|
|
<emphasis>service indicator</emphasis> is defined as any indicator that is
|
|
used in the course of servicing a system. The intent of service
|
|
indicators is
|
|
<emphasis>not</emphasis>, in general, to increase system Error Detection
|
|
and Fault Isolation (EDFI), but rather to guide the user in performance
|
|
of a service action. Usages include (but are not limited to):</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Dynamic Reconfiguration (LoPAR indicator type 9002) to indicate
|
|
the status of DR operations on a Field Replacable Unit (FRU). More
|
|
information on DR indicators can be found in
|
|
<xref linkend="dbdoclet.50569342_75822" />. This indicator is amber
|
|
<footnote xml:id="pgfId-630879">
|
|
<para>The term “amber” will be used in this chapter to mean
|
|
any wavelength between yellow and amber.</para>
|
|
</footnote>in color except for some legacy implementations which combined
|
|
this indicator with the power indicator, where the color was
|
|
green.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An indication of a fault condition of a FRU (LoPAR indicator
|
|
type 9006, when OS visible). This indicator is amber in color. The FRU
|
|
Fault indicator is handled differently by the platform based on whether
|
|
or not the platform is Lightpath Mode platform or Guiding Light
|
|
Mode:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>For Guiding Light Mode platforms, FRU fault indicators are
|
|
transparent to the software and therefore have some very specific
|
|
requirements relative to their very localized behavior. In this case,
|
|
although FRU Fault indicators themselves are transparent to the software,
|
|
the associated failure itself, which would activate a FRU Fault
|
|
indicator, will be available to the software that handles serviceable
|
|
events.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For Lightpath Mode platforms, a FRU fault indicator will be
|
|
available to the software and is activated by the detector of the error.
|
|
In addition, the FRU Fault rolls up to an Enclosure Fault
|
|
indicator.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A system-wide indication of a fault or some condition needing
|
|
attention in the system. An Error Log indicator (LoPAR indicator type
|
|
9006) is an example of an OS-visible
|
|
<footnote xml:id="pgfId-648471">
|
|
<para>For a definition of the visibility or transparency of an
|
|
indicator, see
|
|
<xref linkend="dbdoclet.50569347_63097"/>.</para>
|
|
</footnote>indicator of this class of indicators. The Error Log indicator
|
|
is a flag to the user that there is something in the system needing
|
|
attention, and therefore a starting point to indicate that they should
|
|
begin the isolation procedures to determine what needs attention. In a
|
|
partitioned system, the physical Error Log
|
|
<footnote xml:id="pgfId-632877">
|
|
<para>If the term “virtual” does not appear before
|
|
“Error Log”, then the text is referring to the physical
|
|
Error Log indicator.</para>
|
|
</footnote>indicator may be the logical OR of individual virtual Error
|
|
Log indicators (one virtual Error Log indicator per logical partition and
|
|
one for each other separate entity that is non-partition related). This
|
|
indicator is amber in color.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An indication of an Identify (locate) operation. An Identify
|
|
indicator (LoPAR indicator type 9007) is an example of an indicator of
|
|
this class. These indicators may or may not be visible to an OS. In this
|
|
capacity, the indicator is activated
|
|
<footnote xml:id="pgfId-664224">
|
|
<para>For a definition of what “activate” means, see
|
|
<xref linkend="dbdoclet.50569347_12130" />.</para>
|
|
</footnote>at the user’s request in order to help them locate a
|
|
component in the system (for example, a FRU, a connector, an enclosure,
|
|
etc.). This indicator is amber in color, except for the Enclosure, Rack,
|
|
and Row Identify indicators, which are blue in color.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An indication of the power state of an entity. This indicator is
|
|
platform controlled and is transparent to the OS(s). In addition to the
|
|
power state, this indicator may be used to indicate a power failure or
|
|
fault. This indicator is green in color.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Environmental indicators such as ambient temperature too high.
|
|
These are transparent to the OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Hardware only indicators such as Ethernet activity indicators.
|
|
These are transparent to the OS.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_16804">
|
|
<title>Service Indicator Modes</title>
|
|
<para>There are two modes that a platform can operate in relative to
|
|
service indicators: Lightpath Mode and Guiding Light Mode. Any particular
|
|
|
|
<emphasis>platform</emphasis> operates in one and only one mode relative
|
|
to service indicators: Lightpath Mode or Guiding Light Mode. A
|
|
<emphasis>component</emphasis> (hardware, firmware, or software) which is
|
|
designed to be used in both a Lightpath Mode and a Guiding Light Mode
|
|
platform needs to be able to operate in both modes.</para>
|
|
<para>For guidance in which mode a platform should be designed to
|
|
operate, see
|
|
<xref linkend="dbdoclet.50569347_82731"/>.</para>
|
|
<para>The following sections give an overview of these two modes. For
|
|
specific requirements of each mode, see
|
|
<xref linkend="dbdoclet.50569347_24150"/>.</para>
|
|
|
|
<section>
|
|
<title>Lightpath Mode</title>
|
|
<para>The
|
|
<emphasis>Lightpath Mode</emphasis> specifies a platform implementation of
|
|
service indicators much like what industry-standard servers originally
|
|
implemented with its Lightpath, except that FRU indicators also implement
|
|
an Identify state along with the current Fault state. The Identify state
|
|
overrides the Fault state while the Identify is active for an indicator,
|
|
and the indicator is put into the Fault state, if one is pending, when
|
|
the Identify is removed.</para>
|
|
<para>A summary of the Lightpath Mode is as follows (see
|
|
<xref linkend="dbdoclet.50569347_24150"/> for detailed
|
|
requirements):</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>FRU Fault indicators are used as the general way to identify
|
|
failing FRUs.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The physical indicator that implements the Fault indicator states
|
|
also implements the Identify indicator states (that is, a FRU Fault
|
|
indicator is also a FRU Identify indicator for the same FRU).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This mode is basically a superset of the Guiding Light
|
|
Mode.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>FRU Fault indicators are presented to the OS for FRUs for which
|
|
the OS image is expected to detect errors for either the entire FRU or
|
|
part of the FRU. In the latter case, this represents a shared FRU, in
|
|
which case the FRU Fault indicator is virtualized, so that one partition
|
|
cannot view the setting by another partition, which would allow a covert
|
|
storage channel (see also
|
|
<xref linkend="dbdoclet.50569347_55025"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The OS and firmware are responsible for activating the FRU Fault
|
|
indicator for a FRU for which they detect an error. Fault indicators are
|
|
reset by the service action on the failing part that they
|
|
represent.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>FRU Identify indicators are presented to the OS for FRUs that are
|
|
fully owned by the OS image. They may also be presented for FRUs that are
|
|
partially owned by the OS image. Ownership of a FRU by the OS image is
|
|
defined as being the condition of the FRU being under software control by
|
|
the OS, a device driver associated with the OS, or application software
|
|
running on the OS. In the partially owned case, this represents a shared
|
|
FRU, in which case the FRU Identify indicator is virtualized, so that one
|
|
partition cannot view the setting by another partition, which would allow
|
|
a covert storage channel (see also
|
|
<xref linkend="dbdoclet.50569347_55025" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Connector Identify indicators are presented to the OS for
|
|
connectors that are fully owned by the OS image. Ownership of a connector
|
|
by the OS image is defined as being the condition of the connector being
|
|
under software control by the OS, a device driver associated with the OS,
|
|
or application software running on the OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Enclosure Identify indicators are available to the OS when the OS
|
|
fully owns a FRU in the enclosure. This indicator is virtualized in a
|
|
partitioned system, so that one partition cannot view the setting by
|
|
another partition, which would allow a covert storage channel.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Error Log indicator or virtual copy thereof (for LPARed
|
|
platforms) is available to each OS image.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>See Requirement
|
|
<xref linkend="dbdoclet.50569347_86824" /> for more information for
|
|
requirements on activation of the Fault indicators.</para>
|
|
<para>The Triple-S UI, when implemented, also adds additional requires to
|
|
Lightpath Mode implementations. See
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Guiding Light Mode</title>
|
|
<para>A summary of the Guiding Light Mode is as follows (see
|
|
<xref linkend="dbdoclet.50569347_24150" /> for detailed
|
|
requirements):</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>FRU Identify indicators are used as the way of identifying
|
|
service procedures like repair, reconfiguration, and upgrade. FRU
|
|
Identify indicators are activated/deactivated by user via a user
|
|
interface, to identify the FRU(s) involved in the service
|
|
procedure.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>FRU Identify indicators are presented to the OS for FRUs that are
|
|
fully owned by the OS image. Ownership of a FRU by the OS image is
|
|
defined as being the condition of the FRU being under software control by
|
|
the OS, a device driver associated with the OS, or application software
|
|
running on the OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Connector Identify indicators are presented to the OS for
|
|
connectors that are fully owned by the OS image. Ownership of a connector
|
|
by the OS image is defined as being the condition of the connector being
|
|
under software control by the OS, a device driver associated with the OS,
|
|
or application software running on the OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Fault indicators are allowed, but not required, but if provided,
|
|
must be transparent to any OS image, and are reset by the service action
|
|
on the failing part that they represent. To be transparent to an OS means
|
|
that they cannot be controlled by the OS, nor will they interfere with
|
|
any other indicator that is controlled by the OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Enclosure Identify indicators are provided as part of the
|
|
Identify roll-up. Enclosure Identify indicators are available to the OS
|
|
when the OS fully owns a FRU in the enclosure. This indicator is
|
|
virtualized in a partitioned system, so that one partition cannot view
|
|
the setting by another partition, which would allow a covert storage
|
|
channel.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Error Log indicator, or a virtual copy thereof (for LPARed
|
|
platforms), is available to the OS.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_55025">
|
|
<title>Covert Storage Channels</title>
|
|
<para>A
|
|
<emphasis>covert storage channel</emphasis> is a path between two entities
|
|
that can be used to pass data outside the normal data sharing paths like
|
|
LANs. For example, if two OS images were given access to the same
|
|
physical indicator and if each OS image could read the state of the
|
|
indicator, then the indicator can become a single-bit covert storage
|
|
channel between cooperating entities in the two OS images, to pass data
|
|
back and forth. This cannot be allowed, for security reasons, and
|
|
therefore this architecture defines the concept of virtual
|
|
indicators.</para>
|
|
<para>A
|
|
<emphasis>virtual</emphasis> indicator is provided to each OS image for
|
|
each physical indicator that is shared between OS images. The physical
|
|
indicator is activated when any virtual indicator for that physical
|
|
indicator is activated and the physical indicator is deactivated when all
|
|
virtual indicators for that physical indicator are deactivated. The
|
|
general OS image can sense what it is trying to set the indicator to, but
|
|
cannot sense what the other virtual indicators are set to, and hence no
|
|
covert storage channel exists. The exception to the shared access is by a
|
|
trusted Service Focal Point (see
|
|
<xref linkend="dbdoclet.50569347_95432" /> for more details). For more
|
|
information on how virtual indicators affect the physical indicator
|
|
state, see the physical indicator state diagrams later in this
|
|
chapter.</para>
|
|
<para>An OS image in a partitioned system needs to realize that it may
|
|
not have full control over all physical indicators to which it has access
|
|
(that is, needs to realize that the indicators may be virtualized in some
|
|
cases), and in those cases it should not attempt to indicate to the user
|
|
via a user interface the state of the physical indicator which is
|
|
controlled by a virtual indicator.</para>
|
|
<para>Virtual indicators are controlled by the OS for which they are
|
|
generated, except that the platform may activate an OS’ virtual
|
|
Error Log indicator if the partition in which the OS resides abnormally
|
|
terminates.</para>
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_95432">
|
|
<title>Service Focal Point (SFP) and Service Partition</title>
|
|
<para>The
|
|
<emphasis>Service Focal Point</emphasis> (SFP), when it exists, will
|
|
ultimately be the exclusive common point of control in the system for
|
|
handling all service actions which are not resolved otherwise (for
|
|
example, via Fault indicators). It interfaces with the error log where
|
|
all the serviceable events are stored from the various OS and service
|
|
processor diagnostics. The SFP, among other things, allows resetting of
|
|
the Error Log light by the user, allows controlling the activation and
|
|
deactivation of the FRU, connector, and Enclosure Identify indicators,
|
|
and allows the clearing of the service actions in the error log.</para>
|
|
<para>The SFP shares access to some of the same indicators as one or more
|
|
OS images, but needs access to the physical indicator state, and
|
|
sometimes the state of all the virtual indicators for that physical
|
|
indicator. If the SFP in a partitioned system were to be implemented on
|
|
an OS image that runs non-trusted applications, then the SFP partition
|
|
could not be given access to the physical and other OS’ virtual
|
|
service indicators, or covert storage channels would exist (see
|
|
<xref linkend="dbdoclet.50569347_55025" />) between the SFP partition and
|
|
the other OS partitions. This architecture assumes that the SFP is
|
|
implemented as trusted or
|
|
<emphasis>privileged</emphasis> entity which does not allow non-trusted
|
|
applications running on the same OS image as the SFP, and therefore
|
|
covert storage channels are not considered to exist between the
|
|
SFP’s privileged OS image and other OS images in the system.</para>
|
|
<para>The SFP may also be implemented on as a separate entity from the
|
|
one being monitored. A system management entity like an HMC interfacing
|
|
to the platform via firmware interfaces, or an external system management
|
|
entity, are examples of such implementations.</para>
|
|
<para>For Lightpath Mode, the Triple-S UI is a user interface that is
|
|
associated with a SFP. See
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
<para>The platform’s physical indicators are accessible to the SFP
|
|
through the normal indicator interface (LoPAR indicator types 9006 and
|
|
9007).</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Logical Indicators vs. Physical Indicators</title>
|
|
<para>A physical indicator is, in many cases, used to represent several
|
|
logical and/or virtual indicators. For example, a physical FRU indicator
|
|
can be used in Lightpath Mode to represent both a FRU Identify indicator
|
|
and a FRU Fault indicator.</para>
|
|
<para>The hardware/firmware that implements the physical
|
|
indicator’s state machine is the entity which knows about the
|
|
combining of the logical and virtual into the physical, and higher level
|
|
software (OS and applications) that are given control of a logical or
|
|
virtual indicator are only aware of the control of that logical or
|
|
virtual indicator, and may not be even able to sense the state of the
|
|
physical indicator (that is, can only sense the state of their logical or
|
|
virtual ones).</para>
|
|
<para>The physical indicator state diagrams in
|
|
<xref linkend="dbdoclet.50569347_69815" /> indicate how logical and
|
|
virtual indicators are merged into the physical ones. See also
|
|
<xref linkend="dbdoclet.50569347_55025" /> relative to virtual
|
|
indicators.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_82731">
|
|
<title>Machine Classes and Service Strategy</title>
|
|
<para>Two broad classifications of computer implementations are defined
|
|
here for purposes of defining service indicator implementations.
|
|
<xref linkend="dbdoclet.50569347_67562" /> shows the comparison of these
|
|
classes.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_67562">
|
|
<title>Machine Classifications and Service
|
|
Characteristics</title>
|
|
<?dbhtml table-width="75%" ?>
|
|
<?dbfo table-width="75%" ?>
|
|
<tgroup cols="3">
|
|
<colspec colname="c1" colwidth="33*" align="center" />
|
|
<colspec colname="c2" colwidth="33*" align="center" />
|
|
<colspec colname="c3" colwidth="33*" align="center" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Characteristic</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Simple Class</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Complex Class</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Number of FRUs</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Few</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Many</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Servicing performed by</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Customer, generally</para>
|
|
</entry>
|
|
<entry>
|
|
<para>CE more than customer</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Deferred maintenance</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Very little</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Enabled as much as possible
|
|
<footnote xml:id="pgfId-667002">
|
|
<para>Deferred maintenance is one of the big drivers towards
|
|
use of Guiding Light mode or Lightpath Mode with Triple-S.
|
|
That is, having many Fault indicators active at one time
|
|
(FRUS waiting for service actions) can lead to confusion when
|
|
service is being performed.</para>
|
|
</footnote></para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Concurrent maintenance</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Generally limited to redundant components (fans, power
|
|
supplies) and I/O devices</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Generally a higher level of concurrent maintenance</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Value of a FRU Fault indicator</para>
|
|
</entry>
|
|
<entry>
|
|
<para>High</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Questionable value due to complexity of the system</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>FRU Fault indicator implementation</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Realistic</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Complex, given the higher level of deferred and
|
|
concurrent maintenance</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Console interface</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Rare</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Standard</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Platform service mode</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Lightpath Mode platform</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Guiding Light Mode platform</para>
|
|
<para>or</para>
|
|
<para>Lightpath Mode with Triple-S UI</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Determining whether a platform’s classification, and
|
|
therefore the service mode of the platform is dependent on the product
|
|
requirements, and is beyond the scope of this architecture, but might
|
|
include:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The RAS requirements for the platform. The considerations for
|
|
this come from
|
|
<xref linkend="dbdoclet.50569347_67562" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The mixture of machines expected in the environment. Although the
|
|
Lightpath Mode and the Guiding Light Mode both contain the identify
|
|
capability, and that could be considered to be the common denominator in
|
|
servicing in a mixed environment, it could be that there are more
|
|
Lightpath Mode platforms in the environment for which a new platform
|
|
design is targeted, and therefore it might be desirable to make that new
|
|
platform’s mode of operation be the Lightpath Mode for that
|
|
reason.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
<section>
|
|
<title>General Information about Service Indicators</title>
|
|
<para>Indicators may serve multiple uses, but only as defined by this
|
|
architecture. For example, a physical indicator used for a FRU is used
|
|
for both the FRU Fault and FRU Identify indicators. Non-architected
|
|
usages of an architected indicator are specifically disallowed by this
|
|
architecture.</para>
|
|
<para>In some cases, an indicator may not be visible directly by the user
|
|
without removing covers, components, etc. In this case, there is required
|
|
to be one or more indicators that are higher in the hierarchy which get
|
|
activated in conjunction with the target indicator. This functionality is
|
|
called indicator
|
|
<emphasis>roll-up</emphasis>. Due to the hierarchy, there might be
|
|
multiple indicators that get rolled-up into a single indicator. The
|
|
platform (not the OS) is responsible for indicator roll-up. An example of
|
|
a roll-up is that on the front of an enclosure
|
|
<footnote xml:id="pgfId-634084">
|
|
<para>Note that the enclosure is sometimes called the
|
|
“unit,” but a unit is not necessarily a drawer and a drawer
|
|
is not necessarily a unit, so the term “unit” is not be
|
|
used here. Also note that an enclosure might be a drawer in a rack or
|
|
might be part of a drawer. For example, some I/O drawers consist of two
|
|
separate and independent enclosures. So, sometimes there may be
|
|
multiple enclosure indicators per rack drawer. See also
|
|
<xref linkend="dbdoclet.50569347_12130" />.</para>
|
|
</footnote>in a rack there is a summary LED that summarizes the Identify
|
|
LEDs within or on the back of the enclosure in a rack, and then the
|
|
multiple enclosure summary LEDs are summarized at the rack level with a
|
|
light on the top of the rack. Another example of a roll-up indicator is
|
|
the Enclosure Fault indicator on each enclosure in Lightpath Mode
|
|
platforms, which summarizes the Fault indicators within the enclosure.
|
|
These roll-up indicators are transparent to the OS, and sometimes to the
|
|
firmware, with the exception that the enclosure level Identify indicators
|
|
(or virtual versions thereof, in the case of partitioned systems) may be
|
|
accessible to the OS via the 9007 indicator type. The indicators that are
|
|
provided for roll-up from FRU to enclosure to rack are identified by this
|
|
architecture. Platforms may have unique indicators which are not visible
|
|
to the OS and which are not defined by this architecture. These will not
|
|
share the same indicator as used by one of the indicators which is
|
|
architected, including indicators in the roll-up path, except as
|
|
explicitly allowed by the architectural requirements in this
|
|
architecture. In addition to the roll-up to a higher level indicator for
|
|
visibility, the platform may also provide duplicate indicators for some
|
|
of the indicators. For example, there may be a front and rear indicator
|
|
for the enclosure indicators. These duplicate indicators are not defined
|
|
by this architecture except that as for roll-up indicators, the platform
|
|
is responsible for controlling any duplicate indicators and for not
|
|
making the duplicates visible to the controlling entities. Finally, FRU
|
|
indicators are required to be visible to the user during a service
|
|
action. This may require, for example, that the indicator be able to be
|
|
lit after power is removed from the system, requiring storage of power on
|
|
the component with the indicator (for example, via a capacitor) and
|
|
activation of the indicators by a push button by the user.</para>
|
|
<para>An OS image is given access to the FRU Identify indicators when the
|
|
OS image fully owns the resources, and is given access to the Enclosure
|
|
Identify indicator for any enclosure in which the OS image fully owns any
|
|
resource. An OS image is given access to the FRU Fault indicators when
|
|
the OS image owns all or part of the FRU. The Enclosure Fault indicators
|
|
are roll-up only indicators and access to these indicators are not given
|
|
to the OS.</para>
|
|
<para>In a partitioned system (logical or physical), there may be several
|
|
virtual Enclosure Identify indicators and one physical Enclosure Identify
|
|
indicator. In this case, the OS images are only given access to their
|
|
copy of the virtual Enclosure Identify indicator, and do not have direct
|
|
access to the physical Enclosure Identify indicator. Activating any
|
|
virtual Enclosure Identify indicator which is associated with an
|
|
enclosure activates the physical one for that drawer (if not already
|
|
activated). Turning off the last virtual Enclosure Identify indicator for
|
|
an enclosure turns off the physical one for that enclosure, providing all
|
|
other Identify indicators in the enclosure are also off. If software in a
|
|
partition senses the state of the virtual Enclosure Identify indicator,
|
|
it needs to take into consideration that it may be seeing the virtual
|
|
state and not the real state of the indicator, with the virtual state
|
|
being what the partition set the indicator to, and this is not
|
|
necessarily what the physical indicator is actually displaying.</para>
|
|
<para>The Error Log indicator is located on the System Enclosure (the CEC
|
|
enclosure) and is used to indicate that there was a failure in the
|
|
system. This indicator may also be used by the system to indicate that
|
|
some other attention is needed in the system. This Error Log indicator is
|
|
the starting point for the determination of the necessary action by the
|
|
user.</para>
|
|
<para>In a partitioned system (logical or physical), there may be several
|
|
virtual Error Log indicators and one physical Error Log indicator.
|
|
Activating a virtual Error Log indicator activates the physical one.
|
|
Turning off the last virtual Error Log indicator turns off the physical
|
|
one. If software in a partition senses the state of the Error Log
|
|
indicator, it needs to take into consideration that it may be seeing the
|
|
virtual state and not the real state of the indicator, with the virtual
|
|
state being what the partition set the indicator to, and this is not
|
|
necessarily what the physical indicator is actually displaying.</para>
|
|
<para>For Guiding Light Mode platforms, the FRU Identify indicators are
|
|
the primary method for pointing to failing FRUs. For Lightpath Mode
|
|
platforms, it is expected that the FRU Identify indicators will be used
|
|
as a secondary assistance for FRU fault identification (the FRU Fault
|
|
indicators being the primary). In both cases, the FRU Identify indicators
|
|
can be used to assist with such things as identifying where an upgrade
|
|
should be inserted.</para>
|
|
<para>The general rules for activation and deactivation of indicators can
|
|
be found in Requirements
|
|
<xref linkend="dbdoclet.50569347_96910" /> and
|
|
<xref linkend="dbdoclet.50569347_65011" />, and more explicit
|
|
requirements of individual indicators in the state diagrams in
|
|
<xref linkend="dbdoclet.50569347_69815" />. When the Triple-S UI is
|
|
implemented, see also
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
<para>This architecture assumes that the control of multiple users doing
|
|
identify operations at the same time, is under procedural control, and is
|
|
not handled or controlled in any way by this architecture, OS, or
|
|
firmware.</para>
|
|
<para>For Guiding Light Mode platforms, if a FRU contains a Fault
|
|
indicator, then the Fault indicator is transparent to the OS and control
|
|
of the FRU-level Fault indicator is entirely up to the FRU or to some
|
|
OS-transparent method. For example, some power supplies contain a Fault
|
|
indicator that does not get reported directly to the system controlling
|
|
entity and which is turned off by a button on the power supply which is
|
|
pushed when the service is complete.</para>
|
|
</section>
|
|
<section xml:id="dbdoclet.50569347_70115">
|
|
<title>Secondary Light Panels</title>
|
|
<para>A secondary light panel may be used to house roll-up indicators as
|
|
indicated in the “intermediate” level or
|
|
“secondary” level indicators in
|
|
<xref linkend="dbdoclet.50569347_41855" /> and
|
|
<xref linkend="dbdoclet.50569347_10334" />. These panels may also house
|
|
other indicators which would otherwise not have a home (for example, an
|
|
over-temperature indicator).</para>
|
|
<para>Secondary light panels indicators are not to be used as replacement
|
|
for FRU-level indicators. However, if an indicator is not directly
|
|
visible when the unit is placed into the service position (for example,
|
|
blocked by covers, baffles, cables, etc.), then the secondary light panel
|
|
is one implementation to get around this restriction (other
|
|
implementations may exist, for example light pipes, etc.).</para>
|
|
</section>
|
|
<section xml:id="dbdoclet.50569347_49927">
|
|
<title>Group Identify Operation</title>
|
|
<para>In some systems it may be desirable to identify a set of enclosures
|
|
as being part of a group. This is called a group identify operation and
|
|
can be performed by activating the appropriate Enclosure Identify
|
|
indicators.</para>
|
|
<para>For platform or systems that consist of multiple enclosures, it may
|
|
be necessary to change the state of one enclosure before servicing
|
|
another enclosure. For example, a system drawer (primary enclosure) may
|
|
need to be powered down before servicing an I/O drawer (secondary
|
|
enclosure). It may be useful in this case for the servicer to be able to
|
|
identify the various enclosures that are linked. In such implementations,
|
|
the enclosures should be designed with a method to activate the Group
|
|
Identify function, with the “group” being all linked
|
|
enclosures. One implementation of this is to put a pushbutton in
|
|
proximity to the blue Enclosure Identify indicator, which is then used to
|
|
activate the blue Enclosure Identify indicators of all connected
|
|
enclosures, and subsequently to deactivate all of them. It is suggested
|
|
that with this implementation of the Group Identify function, that this
|
|
switch toggle the Group Identify function for this set of enclosures,
|
|
with each push toggling the Group Identify function. If it takes awhile
|
|
to activate all the blue Enclosure Identify indicators in the group, it
|
|
may be useful to give the user feedback that the button has been pressed.
|
|
One way to do this is to put the blue Enclosure Identify indicator next
|
|
to the pushbutton into the blink state (momentarily) until all the other
|
|
blue Enclosure Identify indicators in the group have been activated, and
|
|
when that is complete, to put this indicator into the Identify state (on
|
|
solid).</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>System-Level Diagrams</title>
|
|
<para>The following figures are conceptual diagrams showing indicator
|
|
roll-ups:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><xref linkend="dbdoclet.50569347_41855" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><xref linkend="dbdoclet.50569347_10334" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><xref linkend="dbdoclet.50569347_69209" />.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_41855">
|
|
<title>Representation of the Indicators -- Lightpath Mode Platform</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-34.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-34.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_10334">
|
|
<title>Representation of the Indicators -- Guiding Light Mode Platform</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-36.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-36.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_69209">
|
|
<title>Representation of the Indicators -- Rack System</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-37.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-37.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<para><emphasis role="bold">Note:</emphasis> Guiding Light Mode platform shown,
|
|
with optional Enclosure Fault indicators. For Lightpath Mode platforms,
|
|
FRU Fault indicators would always exist and would roll up to the Enclosure
|
|
Fault indicator, and additionally, the Rack and Row Identify indicators would
|
|
have an additional Fault indicator (not shown) and the Fault indicators at the
|
|
enclosure level would roll up to those.</para>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_24150">
|
|
<title>Service Indicator Requirements</title>
|
|
<para>Service indicators are required on all platforms.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>All platforms must implement either the
|
|
Lightpath Mode or the Guiding Light Mode of service indicators, and all
|
|
components and enclosures (the primary enclosure and any secondary
|
|
enclosures (for example, I/O expansion drawers)) within the platform must
|
|
be operating in the same mode.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>Indicators defined by this architecture must
|
|
not be used for any purpose other than is what is specified by this
|
|
architecture, and only with the specific states defined by this
|
|
architecture.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_24150"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para>All platforms must provide the
|
|
<emphasis role="bold"><literal>“ibm,service-indicator-mode”</literal></emphasis> property in
|
|
the Open Firmware Device Tree root node.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
|
|
<section xml:id="dbdoclet.50569347_83698">
|
|
<title>Service Indicator General Requirements</title>
|
|
<para>This section details requirements of indicators that are not
|
|
specifically LoPAR indicator type 9006 or 9007 related. These are true
|
|
even if the platform does not present any 9007 indicators to the OS. This
|
|
includes requirements for platform actions like roll-up. For 9006 and
|
|
9007 specific requirements, see
|
|
<xref linkend="dbdoclet.50569347_84242" />.</para>
|
|
<para>Requirements which are prefaced by
|
|
“<emphasis role="bold">For Lightpath Mode platforms:</emphasis>”
|
|
only apply to
|
|
Lightpath Mode platforms. Requirements which are prefaced by
|
|
“<emphasis role="bold">For Guiding Light Mode platforms:</emphasis>”
|
|
only apply
|
|
to Guiding Light Mode platforms. Requirements that are prefaced by
|
|
neither, apply to both Lightpath Mode and Guiding Light Mode platforms.
|
|
<emphasis>Components</emphasis> which are designed to work in both
|
|
Lightpath Mode and Guiding Light Mode platforms, need to be able to
|
|
comply with both Lightpath Mode and Guiding Light Mode sets of
|
|
requirements, as well as the requirements that apply to all.</para>
|
|
|
|
<section xml:id="fault_detection_pd">
|
|
<title>Fault Detection and Problem Determination
|
|
Requirements</title>
|
|
<para>There are two general classifications of problems which are
|
|
indicated by Service Indicators:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>An indication for FRUs that have failed and need to be
|
|
replaced</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An indication of other system problems that may be causing
|
|
performance degradation or which might cause failures in the future, for
|
|
example:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A FRU that is predicted to fail (may be treated as a failing FRU
|
|
by some implementations)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>An over temperature conditions</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A loss of redundancy that is not caused directly by a FRU failure
|
|
(for example, greater than 100% of the power of the base power being
|
|
used)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A configuration problem such as a missing resource, resource
|
|
plugged into the wrong slot, or invalid configuration</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The general model for use of the Error Log
|
|
<footnote xml:id="pgfId-667296">
|
|
<para>Previously called the System Information (Attention)
|
|
indicator.</para>
|
|
</footnote>and Enclosure Fault indicators is to indicate problems as
|
|
follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Activation of either the Error Log or Enclosure Fault indicators
|
|
is accompanied by a log entry in an error log that can be queried by the
|
|
user</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Activation of the Error Log indicator is used when the user needs
|
|
to perform some procedure, or acknowledge some condition, prior to taking
|
|
corrective action</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>For most types of problems, this requires the user to look into
|
|
the error log at the start of the procedure</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In some cases (generally for more common or more urgent
|
|
problems), additional indicators may be provided by a system and
|
|
activated to allow the user to determine the problem without looking into
|
|
the error log (these additional indicators are generally not allowed to
|
|
be the same indicators as defined by this architecture, except as allowed
|
|
by this architecture)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The procedure performed by the user may include items
|
|
like:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Activation of FRU Identify indicators (for example, as in Guiding
|
|
Light Mode systems)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Removal and re-connection of cables, reseating of cards,
|
|
etc.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Activation of an Enclosure Fault (Lightpath Mode systems) is only
|
|
allowed in the following cases:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>As an indication of the roll-up of a FRU Fault indicator</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In conjunction with a system error that prevents a FRU Fault
|
|
indicator from being activated (this requires some other indication of
|
|
the global failure problem, for example, an error code on an op
|
|
panel)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The following requirements define the actions to be taken by a
|
|
system on the detection of a fault.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_86824">
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>The detector of a fault condition must do the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem xml:id="dbdoclet.50569347_67687">
|
|
<para>If the a fault
|
|
occurs which cannot be isolated appropriately without the user performing
|
|
some procedure, then activate the Error Log indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_99028">
|
|
<para>If a fault occurs
|
|
which can be isolated to a single FRU and if there exists a Fault
|
|
indicator for the FRU, then activate that FRU Fault indicator, otherwise
|
|
activate the Error Log indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_76215">
|
|
<para>If a fault occurs
|
|
which cannot be isolated to a single FRU and if there exists a Fault
|
|
indicator for the most likely FRU in the FRU list, then activate that FRU
|
|
Fault indicator, otherwise activate the Error Log indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_27853">
|
|
<para>If a fault occurs
|
|
which is isolated to a group of FRUs (called a FRU group) and if there
|
|
exists a Fault indicator for each of the FRUs, then activate all the FRU
|
|
Fault indicators, otherwise activate the Error Log indicator.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>See also,
|
|
<xref linkend="dbdoclet.50569385_36278" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For
|
|
Compatibility)</emphasis></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_96910">
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para>Service Indicators (Error Log, Fault, and Identify) must be activated
|
|
appropriately to guide a user to or through a service action or
|
|
procedure.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_65011">
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para>Service Indicators (Error Log, Fault, and Identify) must be deactivated
|
|
appropriately, as follows:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>A Service Indicator activated by an entity must be automatically
|
|
deactivated by that entity when that entity can determine that the
|
|
activation is no longer necessary, or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A Service Indicator must be automatically deactivated by the
|
|
platform when the platform can determine that the activation is no longer
|
|
necessary or may be necessary but will be redetected and therefore
|
|
reactivated a reasonable time later, or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A Service Indicator must be automatically deactivated by a
|
|
service procedure which fixes the issue that caused the indicator to be
|
|
automatically activated in the first place, or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A Error Log or Identify indicator must be deactivated when a
|
|
user request it to be deactivated by a system-level user
|
|
interface.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For the Lightpath UI Base Enablement, as indicated in
|
|
Requirement
|
|
<xref linkend="dbdoclet.50569347_68068"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_17117"
|
|
xrefstyle="select: labelnumber"/> and
|
|
<xref linkend="dbdoclet.50569347_43836"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_37801"
|
|
xrefstyle="select: labelnumber"/>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_17215">
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
|
<listitem xml:id="dbdoclet.50569347_17215_text">
|
|
<para>For each
|
|
activation of the Error Log and Enclosure Fault Indicators, one of the
|
|
following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem xml:id="dbdoclet.50569347_39541">
|
|
<para>If the platform
|
|
is functional enough to allow it, then an associated entry must be made
|
|
in an error log that can be queried by a user interface.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_22743">
|
|
<para>In the case where
|
|
the platform is not functional enough to allow logging of an error log
|
|
entry, then there must exist a way for the user to determine the failure
|
|
associated with the indicator activation (for example, an error code on
|
|
an op panel on the system).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" /> are intentionally written
|
|
general enough so that different platform types have some latitude in
|
|
implementation of Service Indicators. However, see the state diagrams,
|
|
<xref linkend="dbdoclet.50569347_69815" />, for some explicit
|
|
requirements for activation and deactivation of the various Service
|
|
Indicators. Those state diagrams take precedence over Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" />. When the state diagrams and
|
|
Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" /> do not give explicit direction
|
|
for implementation, implementers should consider compatibility with
|
|
existing implementations when making decisions about activation and
|
|
deactivation.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>2. In Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" />, the physical indicator may
|
|
not be turned off when deactivated from an OS interface (versus a
|
|
system-level interface), if another entity outside of that OS also has
|
|
the physical indicator activated. That is, if the physical indicator is
|
|
the combination of several logical indicators.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_38463">
|
|
<term><emphasis role="bold">R1-<xref linkend="fault_detection_pd"
|
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
|
<listitem>
|
|
<para xml:id="dbdoclet.50569347_38463_text">The Error Log
|
|
indicator must be activated only for Serviceable Events. Serviceable
|
|
Events are platform, global, regional and local error events that require
|
|
a service action and possibly a call home when the serviceable event must
|
|
be handled by a service representative or at least reported to the
|
|
service provider. Activation of the Error Log indicator notifies the
|
|
customer of the event and the event indicates to the customer that there
|
|
must be some intervention to rectify the problem. The intervention may be
|
|
a service action that the customer can perform or it may require a
|
|
service provider.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="fru-level_connector_indicator">
|
|
<title>FRU-Level and Connector Indicator Requirements</title>
|
|
<para>The indicators specified in this section represent the lowest level
|
|
indicators in the indicator roll-up hierarchy.</para>
|
|
<para>See also requirements in
|
|
<xref linkend="dbdoclet.50569347_71852" />.</para>
|
|
<para>For the Lightpath UI, see also the requirements in
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_82786">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode platforms:</emphasis>
|
|
All of the following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>A FRU Fault indicator must be implemented for every replaceable
|
|
FRU, with the states of “off” and “on,” except
|
|
for FRUs which are excepted in Requirement
|
|
<xref linkend="dbdoclet.50569347_79405" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Clearing of the FRU Fault indicator from the Fault state must be
|
|
the result of part of the repair action and must be transparent to the
|
|
OS(s) and SFP (that is, the OS or SFP is not required to automatically
|
|
clear a FRU Fault indicator).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The physical indicator which implements the FRU Fault indicator
|
|
must also be Identify indicator and follow the requirements for Identify
|
|
indicators.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_69299">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>FRU indicators
|
|
(Fault and Identify) must be visible to the user during a service
|
|
action.</para>
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> Requirement
|
|
<xref linkend="dbdoclet.50569347_69299" /> may require, for example, that
|
|
the indicator be able to be lit after power is removed from the system,
|
|
requiring storage of power on the component with the indicator (for
|
|
example, via a capacitor) and activation of the indicators by a push
|
|
button by the user (see Requirement
|
|
<xref linkend="dbdoclet.50569347_66721" /> for requirements on this
|
|
implementation). Another example would be via the use of a light pipe
|
|
from the indicator to a visible place.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_90666">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For Guiding Light Mode platforms:</emphasis>
|
|
If a FRU Fault
|
|
indicator exists, then it must be transparent to the OS, SFP, and HMC and
|
|
it must be independent of, and not physically combined into the same
|
|
indicator with, any indicator defined by this architecture, including the
|
|
setting of, resetting of, and displaying of the state of that indicator,
|
|
except that a FRU Identify indicator may be activated to the Fault state
|
|
(on solid) as a result of a FRU failure if all of the following are
|
|
true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The failure that is being indicated must be a failure which
|
|
prevents the user from activating the said FRU Identify indicator to the
|
|
Identify state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Clearing of the FRU Fault indicator must be the result of part
|
|
of the repair action and must be transparent to the OS, SFP, and
|
|
HMC.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Architecture Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>For Guiding Light Mode platforms, the only FRU-level indicators
|
|
that are allowed to be visible to an OS, SFP, or HMC are the FRU Identify
|
|
indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For Guiding Light Mode platforms, the only Fault indicator that
|
|
is allowed to be visible to an OS, SFP, or HMC is the Error Log
|
|
indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Examples of the exception of the use of FRU and enclosure
|
|
indicators in Requirement
|
|
<xref linkend="dbdoclet.50569347_90666" /> as an indication of a fault
|
|
are: when the path for controlling an Enclosure Identify indicator or FRU
|
|
indicator in that enclosure is broken, or when the power supply in the
|
|
enclosure is broken and the indicator cannot be activated to the Identify
|
|
state. In these cases the FRU and/or enclosure indicators may be
|
|
activated (transparently) to the Fault state to indicate the failure, and
|
|
would be returned to the Normal state as a result of the repair action
|
|
that fixes the problem.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_79405">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para>All platforms
|
|
designs, except very low end servers,
|
|
<footnote xml:id="pgfId-631249">
|
|
<para>The term “very low end servers” is not explicitly
|
|
defined here, but is used to refer to implementations where FRU-level
|
|
indicators cannot reasonably be implemented (for example, due to size
|
|
constraints) or where the product can show explicit financial
|
|
justification for not implementing.</para>
|
|
</footnote>must include an Identify indicator for every FRU with the
|
|
states of “off” and “blink,” except for the
|
|
following classes of FRUs:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem xml:id="dbdoclet.50569347_44198">
|
|
<para>If a device
|
|
driver has access to some standard form of Identify/Fault indicators for
|
|
the DASD devices it controls (for example, some standard form of
|
|
enclosure services), then the platform does not need to provide FRU
|
|
indicators for these devices.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_45076">
|
|
<para>If a device
|
|
driver has access to some standard form of Identify/Fault indicators for
|
|
the removable media devices it controls (for example, some standard form
|
|
of enclosure services), then the platform does not need to provide FRU
|
|
indicators for these devices.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_33549">
|
|
<para>External
|
|
enclosures other than PCI expansion enclosures, and external devices (for
|
|
example, keyboard, mice, tablets) that attach via cable to IOAs, do not
|
|
require FRU indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Cables that connect from IOAs to the devices defined in parts
|
|
<xref linkend="dbdoclet.50569347_44198" xrefstyle="select: labelnumber nopage"/>,
|
|
<xref linkend="dbdoclet.50569347_45076" xrefstyle="select: labelnumber nopage"/>, and
|
|
<xref linkend="dbdoclet.50569347_33549" xrefstyle="select: labelnumber nopage"/>
|
|
of this requirement do not require FRU indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Internal cables, interposers, and other FRUs which do not
|
|
contain active components do not require FRU indicators.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> Even though an item falls into
|
|
the list of possible exceptions in Requirement
|
|
<xref linkend="dbdoclet.50569347_79405" />, the designer of such a
|
|
component should verify that leaving off the FRU Identify indicator from
|
|
their component will not prevent the systems in which that component is
|
|
used from meeting their serviceability requirements.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_53442">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
|
<listitem>
|
|
<para>All FRU-level
|
|
Identify indicators must implement the state diagram shown in
|
|
<xref linkend="dbdoclet.50569347_53936" />, except that the Fault state
|
|
is not required for Guiding Light Mode platforms.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_58940">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
|
<listitem>
|
|
<para>All platforms
|
|
must include an Identify indicator with the states of “off”
|
|
and “blink” for every connector that is to be involved in an
|
|
Identify operation.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_24444">
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
|
|
<listitem>
|
|
<para>FRU-level and
|
|
connector-level indicators must be made visible to the OS(s) as follows,
|
|
and must be made transparent otherwise:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem xml:id="dbdoclet.50569347_39945">
|
|
<para><emphasis role="bold">For Lightpath Mode platforms:</emphasis> FRU Fault indicators
|
|
must be made visible to the OS for FRUs for which the OS image is
|
|
expected to detect errors for either the entire FRU or part of the
|
|
FRU.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>FRU Identify indicators must be made visible to the OS for FRUs
|
|
that are fully owned by the OS image.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Connector Identify indicators must be made visible to the OS for
|
|
connectors that are fully owned by the OS image and for which a connector
|
|
Identify indicator exists.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>In Requirement <xref linkend="dbdoclet.50569347_24444"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_39945"
|
|
xrefstyle="select: labelnumber"/>, for FRU Fault indicators that
|
|
are shared, the FRU Fault indicator is virtualized, so that one partition
|
|
cannot view the setting by another partition, which would allow a covert
|
|
storage channel (see also
|
|
<xref linkend="dbdoclet.50569347_55025" /> and
|
|
<xref linkend="dbdoclet.50569347_87607" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ownership of a FRU or connector by the OS image is defined as
|
|
being the condition of the FRU or connector being under software control
|
|
by the OS, a device driver associated with the OS, or application
|
|
software running on the OS.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
|
|
<listitem>
|
|
<para>An OS which activates a FRU Identify
|
|
indicator must provide a method of deactivating that indicator.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="fru-level_connector_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For
|
|
Compatibility)</emphasis></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="enclosure-level_indicator">
|
|
<title>Enclosure-Level Indicator Requirements</title>
|
|
<para>See also requirements in
|
|
<xref linkend="dbdoclet.50569347_71852" />.</para>
|
|
<para>For the Lightpath UI, see also the requirements in
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_11464">
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">On the System Enclosure:</emphasis>
|
|
The platform must
|
|
implement an Error Log indicator and all of the following must be
|
|
true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The states of “off” and “on” must be
|
|
implemented and must be used for the Error Log function</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator must roll-up to the rack indicator, when the rack
|
|
indicator is implemented, and for blade implementations, to the Chassis
|
|
Error Log indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The indicator must implement the state diagram shown in
|
|
<xref linkend="dbdoclet.50569347_44018" />.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_11464_e">
|
|
<para>The platform must provide a mechanism to allow the user to put
|
|
the Error Log indicator into the off state.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>Except for enclosures that contain only
|
|
FRUs that are exempted from FRU-level indicators as specified by
|
|
Requirement
|
|
<xref linkend="dbdoclet.50569347_79405" /> parts
|
|
<xref linkend="dbdoclet.50569347_44198" />,
|
|
<xref linkend="dbdoclet.50569347_45076" />, and
|
|
<xref linkend="dbdoclet.50569347_33549" />, and which also do not have
|
|
any Connector Identify indicators, the platform must implement an
|
|
Enclosure Identify indicator on all enclosures, and all the following
|
|
must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The states of “off,” “blink,” and
|
|
“on” must be implemented and must be used for the Identify
|
|
function.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator must roll-up to the rack indicator, when the rack
|
|
indicator is implemented, and for blade implementations, to the Chassis
|
|
Enclosure Identify indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The indicator must implement the state diagrams shown in
|
|
<xref linkend="dbdoclet.50569347_91006" /> and
|
|
<xref linkend="dbdoclet.50569347_27197" />.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_24076">
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode Platforms:</emphasis> All the following must
|
|
be true for the Enclosure Fault indicator:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The platform must implement an Enclosure Fault indicator on each
|
|
enclosure in which there exists at least one FRU Fault indicator.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>These indicators must implement the states of “off,”
|
|
“on,” and “blip”.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>These indicators must implement the state diagram as shown in
|
|
<xref linkend="dbdoclet.50569347_59067" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>These indicators must not be visible to any OS image.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_66944">
|
|
<para>The platform must
|
|
provide a mechanism to allow the user to put each Enclosure Fault
|
|
indicator into the blip state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator must roll-up to the rack indicator, when the rack
|
|
indicator is implemented, and for blade implementations, to the Chassis
|
|
Enclosure Fault indicator.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> One way of achieving Requirement
|
|
<xref linkend="dbdoclet.50569347_24076"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944"
|
|
xrefstyle="select: labelnumber"/> is to provide a pushbutton (for
|
|
example, on the secondary indicator panel).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_97774">
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
|
<listitem>
|
|
<para>Enclosure-level
|
|
indicators must be made visible to the OS(s) as follows, and must be made
|
|
transparent otherwise:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem xml:id="dbdoclet.50569347_73505">
|
|
<para>Enclosure
|
|
Identify indicators must be made visible to the OS when the OS fully owns
|
|
a FRU in the enclosure.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Error Log indicator must be made visible to each OS image.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>In Requirement
|
|
<xref linkend="dbdoclet.50569347_97774" />, for indicators that are
|
|
shared, the indicator is virtualized, so that one partition cannot view
|
|
the setting by another partition, which would allow a covert storage
|
|
channel (see also
|
|
<xref linkend="dbdoclet.50569347_55025" /> and
|
|
<xref linkend="dbdoclet.50569347_87607" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ownership of a FRU by the OS image is defined as being the
|
|
condition of the FRU being under software control by the OS, a device
|
|
driver associated with the OS, or application software running on the
|
|
OS.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_44224">
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
|
|
<listitem>
|
|
<para>An OS which
|
|
activates an Error Log indicator must provide a method of deactivating
|
|
that indicator, when such an activation is not be deactivated
|
|
automatically as part of the service action.</para>
|
|
<para>
|
|
|
|
<emphasis role="bold">Implementation Note:</emphasis> Relative to Requirement
|
|
<xref linkend="dbdoclet.50569347_44224" />, it is recommended that an OS
|
|
that activates an Error Log indicator, provide a way to deactivate that
|
|
indicator, regardless of whether that indicator would be reset as part of
|
|
a service action.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
|
|
<listitem>
|
|
<para>An OS which activates an Enclosure
|
|
Identify indicator must provide a method of deactivating that
|
|
indicator.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis>(Requirement Number Reserved For Compatibility)</emphasis></para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="enclosure-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For Guiding Light Mode Platforms:</emphasis> If a FRU Fault
|
|
indicator exists, then it must not roll-up to the Enclosure Identify or
|
|
Error Log indicator, and if there is such a requirement to roll-up such
|
|
an indicator, then the enclosure must implement an Enclosure Fault
|
|
indicator, with the same requirements as the Enclosure Fault indicator
|
|
for Lightpath Mode platforms.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="rack-level_indicator">
|
|
|
|
<title>Rack-Level Indicator Requirements</title>
|
|
|
|
<para>See also requirements in
|
|
<xref linkend="dbdoclet.50569347_71852" />.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="rack-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>If a platform implements a rack-level
|
|
indicator then all of the following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The rack indicator must be transparent to the OS, SFP, and
|
|
HMC.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The rack indicator must be Highly visible
|
|
<footnote xml:id="pgfId-629945">
|
|
<para>As defined by our usability groups</para>
|
|
</footnote>(distance and viewing angle) with covers in place.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode:</emphasis> The rack tower indicator must
|
|
implement the state diagram indicated in
|
|
<xref linkend="dbdoclet.50569347_22016" />,
|
|
<xref linkend="dbdoclet.50569347_71112" />, and
|
|
<xref linkend="dbdoclet.50569347_15206" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Guiding Light Mode:</emphasis> The rack tower indicator
|
|
must implement the state diagram indicated in
|
|
<xref linkend="dbdoclet.50569347_22016" />,
|
|
<xref linkend="dbdoclet.50569347_15206" />, and if the optional Enclosure
|
|
Fault indicators are implemented, then
|
|
<xref linkend="dbdoclet.50569347_71112" />.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="row-level_indicator">
|
|
<title>Row-Level Indicator Requirements</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="row-level_indicator"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>If a system implements a row-level
|
|
indicator to roll-up a row of rack-level indicators, then the following
|
|
must be true for these indicators:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The indicator must be transparent to the OS, SFP, and
|
|
HMC.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode:</emphasis> This indicator must implement the
|
|
state diagram indicated in
|
|
<xref linkend="dbdoclet.50569347_46164" />,
|
|
<xref linkend="dbdoclet.50569347_44514" />, and
|
|
<xref linkend="dbdoclet.50569347_96374" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Guiding Light Mode:</emphasis> This indicator must
|
|
implement the state diagram indicated in
|
|
<xref linkend="dbdoclet.50569347_46164" />,
|
|
<xref linkend="dbdoclet.50569347_96374" />, and if the optional Enclosure
|
|
Fault indicators are implemented, then
|
|
<xref linkend="dbdoclet.50569347_44514" />.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_87607">
|
|
<title>Shared Indicator (Multiple Partition System)
|
|
Requirements</title>
|
|
<para>To avoid covert storage channels (see
|
|
<xref linkend="dbdoclet.50569347_55025" />), virtual indicators are
|
|
required for physical indicators which are shared between OS
|
|
images.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_80861">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_87607"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>If a physical
|
|
indicator (Fault or Identify) is shared between more than one partition,
|
|
all the following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Except where there is explicit trust between the partitions, the
|
|
platform must provide a separate virtual indicator to each non-trusted
|
|
partition for each shared physical indicator and must control the
|
|
physical indicator appropriately, as indicated in the state diagrams in
|
|
<xref linkend="dbdoclet.50569347_69815" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If software in a partition senses the state of the virtual
|
|
indicator, it must take into consideration that it is seeing the virtual
|
|
state and not the real state of the indicator, with the virtual state
|
|
being what the partition set the indicator to, and this is not
|
|
necessarily what the physical indicator is actually displaying.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The SFP must be given access (sense and set) to the physical FRU
|
|
level indicators, and the platform must clear all the corresponding
|
|
virtual indicators when physical indicator is cleared by the SFP.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The SFP must be given access (sense and set) to the physical
|
|
Error Log indicator, and the platform must not clear the corresponding
|
|
virtual indicators when physical indicator is cleared by the SFP.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis>Architecture Note:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>In Requirement
|
|
<xref linkend="dbdoclet.50569347_80861" />, an example of “explicit
|
|
trust” is where the sharing partitions are the SFP and one other
|
|
partition, where the SFP is running in an OS where all the applications
|
|
and drivers can be trusted to not open a covert channel to the other OS
|
|
or application in that other partition.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In Requirement
|
|
<xref linkend="dbdoclet.50569347_80861" />, it may be possible for the
|
|
SFP to get direct access to the virtual indicators, but such access is
|
|
beyond the scope of this architecture.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_71852">
|
|
<title>Additional Indicator Requirements</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>A user interface which presents to a
|
|
user the state of the Identify indicators or which allows the user to set
|
|
the state of the Identify indicators, must be prepared for an indicator
|
|
to disappear from the list of indicators available to the OS image (for
|
|
example, a “no such indicator” response to a set request),
|
|
and must provide the user with an appropriate message and recovery (for
|
|
example, prompt the user whether they want to refresh the list of
|
|
available indicators).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>The color of indicators must be as follows:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>FRU Identify, FRU Fault, Enclosure Fault, Error Log indicators,
|
|
and any roll-up indicators for Error Log (rack-level, blade system
|
|
chassis-level, and row-level) must be amber.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The Enclosure Identify indicators and any roll-up indicators for
|
|
these indicators (rack-level, blade system chassis-level, and row-level)
|
|
must be blue.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_81809">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para>The blink rate of
|
|
all Identify indicators which blink, must be nominally 2 Hz (minimum 1
|
|
Hz) with a nominal 50% duty cycle.</para>
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> The 1 Hz rate should not be used
|
|
unless absolutely necessary. The 1 Hz rate is put in to be consistent
|
|
with the industry standard SHPC specification, which specifies 2 Hz with
|
|
1 Hz minimum.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_55538">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para>The
|
|
“blip” rate for the Enclosure Fault indicators when in the
|
|
“remind” state must be nominally 0.5 Hz with a duty cycle of
|
|
0.2 seconds on, 1.8 seconds off.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
|
<listitem>
|
|
<para>All indicator roll-up (activate and
|
|
deactivate) must be controlled entirely by the platform and must be
|
|
transparent to the OS, SFP, and HMC.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
|
<listitem>
|
|
<para>Duplicate indicators that are
|
|
implemented to reflect the same state as another indicator in the system
|
|
(for example, an indicator on the back of an enclosure that is to reflect
|
|
the same visible state as the enclosure indicator on the front of the
|
|
enclosure) must be transparent to the OS and must be kept synchronized by
|
|
the platform.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_11274">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
|
|
<listitem>
|
|
<para>The platform must
|
|
provide a way to light all the indicators (Identify, Fault, Error Log,
|
|
etc.) without any OS present, for test purposes (manufacturing, field
|
|
service, etc.).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
|
|
<listitem>
|
|
<para>The hardware must provide the firmware a
|
|
way to read the state of the indicators (that is, the register which
|
|
controls the visual state, not the actual visual state) as well as to set
|
|
the state of the indicators.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_88831">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
|
|
<listitem>
|
|
<para>The platform must
|
|
be designed such that permanently removing a FRU does not remove the
|
|
capability to use the Identify indicator(s) remaining in the platform or
|
|
affect any roll-up.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_66721">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
|
|
<listitem>
|
|
<para>In reference to
|
|
Requirement <xref linkend="dbdoclet.50569347_24076"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944"
|
|
xrefstyle="select: labelnumber"/>, if a capacitor and pushbutton
|
|
are used to be able to activate the indicator after removal of the part,
|
|
then all the following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode platforms:</emphasis> Both
|
|
the Identify and
|
|
the Fault states must be supported, and the indicator must activate when
|
|
the push button is depressed and must go off (with the remaining
|
|
capacitor charge maintained) when the pushbutton is released (Identify
|
|
state is displayed as “blink” and Fault state as
|
|
“on”).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For Guiding Light Mode platforms:</emphasis>
|
|
The Identify state
|
|
must be supported, and the indicator must activate (“blink”)
|
|
when the push button is depressed and must go off (with the remaining
|
|
capacitor charge maintained) when the pushbutton is released.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_62866">
|
|
<para>There must be a
|
|
green indicator next to the pushbutton and the indicator must get turned
|
|
on when the button is pressed and when there is charge in the capacitor,
|
|
and must be off when the button is not pressed.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The capacitor must have the capability to store enough charge
|
|
for two hours and after that period must be able to light for 30 seconds
|
|
the green indicator and enough other indicators to be able to identify
|
|
any necessary group of FRUs (for example, four additional indicators if a
|
|
group of four DIMM locations is to be identified simultaneously).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> As part of Requirement
|
|
<xref linkend="dbdoclet.50569347_66721" />, it is not necessary to
|
|
roll-up any activated indicators to the next level when the button is
|
|
pressed.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
|
|
<listitem>
|
|
<para>All indicators which are under standby
|
|
power must work the way they do when full power is applied to the system,
|
|
including all of the following:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The indicators must continue to display the last state displayed
|
|
when the system power went to standby-only power, unless the state is
|
|
changed during the standby state by the user or by a service
|
|
action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The changing of the state to the Identify state and then back to
|
|
the previous state by the user must be supported, when that functionality
|
|
is supported during full system power.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> Internal to the platform
|
|
firmware, it will most likely be required to have a common control point
|
|
for all service indicators in order to meet the requirements and meet the
|
|
necessary state information</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-12.</emphasis></term>
|
|
<listitem>
|
|
<para>Any secondary (intermediate) level
|
|
roll-up indicator (see
|
|
<xref linkend="dbdoclet.50569347_70115" />) must behave as
|
|
follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Be blinking, if any Identify indicator that it represents is
|
|
blinking</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Be on solid if any Fault indicator that it represents is on and
|
|
no Identify indicator that it represents is blinking</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Be off if all indicators that it represents are off</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_71852"
|
|
xrefstyle="select: labelnumber nopage"/>-13.</emphasis></term>
|
|
<listitem>
|
|
<para>The icons used for the following indicators, and any
|
|
roll-up of the same, must be as follows (see the usability specifications
|
|
for size, color, and placement):</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>For the Error Log indicator:</para>
|
|
<informalfigure>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-38.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-38.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</informalfigure>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For the Enclosure Fault indicator:</para>
|
|
<informalfigure>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-39.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-39.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</informalfigure>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For the Enclosure Identify indicator:</para>
|
|
<informalfigure>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-40.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-40.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</informalfigure>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="blade_systems_chassis-level">
|
|
<title>Blade Systems Chassis-level Indicator
|
|
Requirements</title>
|
|
<para>The following describes the chassis-level Error Log and Enclosure
|
|
Identify indicator requirements for blade chassis implementations. These
|
|
are basically the same as for the rack and row level indicators, except
|
|
that the Enclosure Identify indicators are required to be able to be
|
|
turned on/off by a user interface, unlike the rack and row level
|
|
indicators.</para>
|
|
<para>For the Lightpath UI, see also the requirements in
|
|
<xref linkend="dbdoclet.50569347_88196" />.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_47650">
|
|
<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>The blade chassis
|
|
must implement an amber Error Log indicator, with the state diagram
|
|
indicated in
|
|
<xref linkend="dbdoclet.50569347_31313" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_95128">
|
|
<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>The blade chassis
|
|
must implement an amber Enclosure Fault indicator, with the state diagram
|
|
indicated in
|
|
<xref linkend="dbdoclet.50569347_48644" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_32909">
|
|
<term><emphasis role="bold">R1-<xref linkend="blade_systems_chassis-level"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para>The blade chassis
|
|
must implement an blue Enclosure Identify indicator, with the state
|
|
diagram indicated in
|
|
<xref linkend="dbdoclet.50569347_20150" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_69815">
|
|
<title>Service Indicator State Diagrams</title>
|
|
<para>The following state diagrams show the transitions and states for
|
|
the service indicators in the system.</para>
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> Activation of an
|
|
indicator by a
|
|
roll-up operation from a lower level indicator will prevent a user from
|
|
turning off such an indicator from a user interface without turning off
|
|
the lower level indicator. It is recommended, if possible, that in the
|
|
user interface that allows the user to attempt to deactivate an
|
|
indicator, provide to the user a message that the indicator cannot be
|
|
deactivated, if attempted, when a roll-up to that indicator is active.
|
|
That is, something better than just silently not turning off the
|
|
indicator. Alternatively, the user can be shown that the option of
|
|
turning off such an indicator is not possible, when a roll-up to that
|
|
indicator is active (for example, by graying out the option on the user
|
|
interface).</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_53936">
|
|
<title>FRU or Connector Fault/Identify
|
|
Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-41.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-41.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Not being available means the failure that is being
|
|
indicated must be a failure which prevents the user from
|
|
activating the Identify for the FRU.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Transition to Fault state may occur if a failure
|
|
occurs which would prevent the activation of the indicator
|
|
into one of the Identify states. Not all FRU Fault indicators
|
|
in an enclosure get activated like this simultaneously;
|
|
only those that are directly involved with the fault
|
|
(for example, like the FRU Fault indicator associated with
|
|
the indicator controller hardware)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><phrase role="red">OS is not expected to change an
|
|
indicator from Fault to Normal, but is permitted to do so
|
|
(providing that it has access to the indicator because it
|
|
owns the resource).</phrase></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><phrase role="red">Transition from Fault to the Identify
|
|
or Normal states by the OS may not be possible if a hardware
|
|
fault causes a failure which prevents access to the
|
|
indicator.</phrase></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Format on the above diagram of “xxxx,y” means a
|
|
call to the <emphasis>set-indicator</emphasis> or
|
|
<emphasis>ibm,set-dynamic-indicator</emphasis>
|
|
RTAS call with an indicator token of “xxxx” and a state
|
|
value of “y” (only the token applicable for the specific
|
|
indicator causes a state transition).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 9002 Identify and Action are the same state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><phrase role="red">9006 FRU-level indicators only
|
|
provided in Lightpath Mode platforms.</phrase></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><phrase role="red">Fault indicators may be virtualized,
|
|
with several OS images and firmware given access to a virtual
|
|
FRU Fault indicator which controls the same physical
|
|
Fault/Identify indicator. These get combined as shown in the state
|
|
diagram, above; all virtual Fault indicators basically get
|
|
ORed together.</phrase></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator may be forced to the Normal (off)
|
|
state under certain circumstances (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><phrase role="red">For the Lightpath UI, when implemented,
|
|
other transition conditions are possible. See
|
|
<xref linkend="dbdoclet.50569347_88196"/>
|
|
for requirements.</phrase></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_44018">
|
|
<title>Error Log
|
|
Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-42.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-42.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Format on the above diagram of “xxxx,y” means
|
|
a call to the <emphasis>set-indicator</emphasis> or
|
|
<emphasis>ibm,set-dynamic-indicator</emphasis>
|
|
RTAS call with an indicator token of “xxxx” and a state
|
|
value of “y” (only the token applicable for the
|
|
specific indicator causes a state transition).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator may be forced to the Normal
|
|
(off) state under certain circumstances (for example, see
|
|
Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>See Requirement
|
|
<xref linkend="dbdoclet.50569347_11464"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_11464_e"
|
|
xrefstyle="select: labelnumber"/>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For the Lightpath UI, when implemented, other transition conditions
|
|
are possible. See
|
|
<xref linkend="dbdoclet.50569347_88196"/>
|
|
for requirements.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_91006">
|
|
<title>Enclosure
|
|
Identify Indicator State Diagram for Scalable Systems</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-43.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-43.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>This indicator may be forced to the Normal (off)
|
|
state under certain circumstances (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).
|
|
This indicator is off at the end of POST.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The states in this diagram overlay the corresponding
|
|
states in
|
|
<xref linkend="dbdoclet.50569347_27197"/>.
|
|
This figure represents the POST states and
|
|
<xref linkend="dbdoclet.50569347_27197" xrefstyle="select: label nopage" />
|
|
the after-POST states.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The use of the Optional Identify state to indicate boot
|
|
identify is only to be used for boot servers
|
|
for scalable system nodes or blades of a blade system
|
|
(for example, NUMA system nodes), and not for stand-alone
|
|
systems or blades</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_27197">
|
|
<title>Enclosure
|
|
Identify Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-44.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-44.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>This indicator may be activated to the on state
|
|
by any OS which is given access to the indicator per Requirements.
|
|
For indicators that are shared by multiple OS instances, this indicator
|
|
is virtualized (see
|
|
<xref linkend="dbdoclet.50569347_55025"/>
|
|
and
|
|
<xref linkend="dbdoclet.50569347_87607"/>).
|
|
LoPAR compliant OSs are only given the capability to activate the
|
|
Enclosure ID to the on state, not to the blink state. The blink state
|
|
may be activated through an external platform management interface by
|
|
a user request through that interface to blink the physical Enclosure ID.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator may be forced to the off state under
|
|
certain circumstances (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).
|
|
This indicator is off at the end of POST.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="Note3">
|
|
<para>A user is not allowed to deactivate the Enclosure ID if
|
|
there are still FRU IDs still active.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A user request through a privileged user interface (for example,
|
|
via an SFP) to set the physical Enclosure ID to off,
|
|
forces any virtual Enclosure ID indicators that are active (on or
|
|
blink) to their off state, but this does not override
|
|
any FRU ID roll-ups (see Note
|
|
<xref linkend="Note3" xrefstyle="select: nopage"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For Scalable (NUMA) systems, the states in this diagram
|
|
overlay the corresponding states in
|
|
<xref linkend="dbdoclet.50569347_91006"/>.
|
|
This figure represents the after-POST states and
|
|
<xref linkend="dbdoclet.50569347_91006" xrefstyle="select: label nopage" />.
|
|
the POST states.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A virtual Enclosure ID can be activated or turned off by the
|
|
9007 indicator token for the target Enclosure ID.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_59067">
|
|
<title>Enclosure Fault
|
|
Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-45.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-45.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>There is no direct activation or deactivation of
|
|
this indicator by any OS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>See Requirement
|
|
<xref linkend="dbdoclet.50569347_24076" xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_66944" xrefstyle="select: labelnumber"/>
|
|
and the Implementation Note below that requirement.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This indicator may be forced to the Normal (off)
|
|
state under certain circumstances (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Activation of an Enclosure Fault indicator without
|
|
activating a FRU Fault indicator within the
|
|
enclosure is to be used only in exceptional cases where
|
|
the FRU Fault cannot be activated. In
|
|
such cases the system is required to also provide
|
|
further direction to the user on how to resolve
|
|
the fault (for example, by providing an error code on an
|
|
op panel on the system).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_31313">
|
|
<title>For Blade Systems:
|
|
Chassis-level Error Log Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-46.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-46.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_48644">
|
|
<title>For Blade Systems:
|
|
Chassis-level Fault Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-47.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-47.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_20150">
|
|
<title>For Blade Systems:
|
|
Chassis-level Enclosure Identify Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-48.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-48.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>This indicator may be forced to the Normal (off) state
|
|
under certain circumstances (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_65011" xrefstyle="select: nopage"/>).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A user is not allowed to deactivate the chassis Enclosure
|
|
ID if there are still FRU Identify or Blade Enclosure
|
|
Identify indicators still active (see state transition qualifiers
|
|
in the above diagram).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A user request to set the Chassis Enclosure ID to the
|
|
Identify (blink) state temporarily overrides roll-up
|
|
operations (roll-up operations set the indicator to the on state).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A user request to change state of the Chassis Enclosure
|
|
ID cancels any previous user request against the
|
|
same indicator, replacing the user requested state with the new state.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</para>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_22016">
|
|
<title>Rack-level Error
|
|
Log Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-49.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-49.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_71112">
|
|
<title>Rack-level Fault
|
|
State Indicator Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-50.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-50.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_15206">
|
|
<title>Rack-level
|
|
Enclosure Identify Indicator State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-51.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-51.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_46164">
|
|
<title>Row-level Error
|
|
Log State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-52.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-52.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_44514">
|
|
<title>Row-level Fault
|
|
State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-53.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-53.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure pgwide="1" xml:id="dbdoclet.50569347_96374">
|
|
<title>Row-level
|
|
Identify State Diagram</title>
|
|
<mediaobject>
|
|
<imageobject role="html">
|
|
<imagedata fileref="figures/PAPR-54.gif" format="GIF"
|
|
scalefit="1" />
|
|
</imageobject>
|
|
<imageobject role="fo">
|
|
<imagedata contentdepth="100%" fileref="figures/PAPR-54.gif"
|
|
format="GIF" scalefit="1" width="100%" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para><emphasis role="bold">Notes:</emphasis> A blinking Enclosure ID
|
|
is assumed to be “active” for purposes of the Row Enclosure ID indicator
|
|
state.</para>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_84242">
|
|
<title>Requirements for 9002, 9006, and 9007 Indicators</title>
|
|
<para>See
|
|
<xref linkend="dbdoclet.50569347_83698" /> for service indicator
|
|
requirements that are not 9006 and 9007 specific.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_74342">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>When the platform
|
|
presents a 9006 indicator to an OS, the following must be true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The platform must set the location code of the Error Log (9006)
|
|
indicator and sensor to be the location code of the system and this
|
|
indicator or sensor must be the first one in the list of 9006 indicators
|
|
or sensors.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><emphasis role="bold">For Lightpath Mode platforms:</emphasis>
|
|
The platform must set
|
|
the location code of each FRU Fault indicator and sensor to be the
|
|
location code of the component to which that indicator or sensor is
|
|
associated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For every 9006 indicator, there must be a corresponding 9006
|
|
sensor which has the same index as the corresponding indicator.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_41932">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>When 9007
|
|
indicators are to be provided to an OS, the platform must implement the
|
|
<emphasis>ibm,get-indices</emphasis> RTAS call and must present that call
|
|
in the device tree for the OS, and the OS needing access to the 9007
|
|
indicators and sensors must use the
|
|
<emphasis>ibm,get-indices</emphasis> call to get the indices of the 9007
|
|
indicators and sensors available to the partition at the time of the
|
|
call.</para>
|
|
<para>
|
|
<emphasis role="bold">Software Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Relative to Requirement
|
|
<xref linkend="dbdoclet.50569347_41932" />, due to Dynamic
|
|
Reconfiguration, the indicators available at any point in time might be
|
|
different than on a previous call to
|
|
<emphasis>ibm,get-indices</emphasis>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>9007 indicators may need to be provided to the OS in the order
|
|
in which they are best displayed to the user, because the OS or the UI
|
|
may not reorder them (for example, sort them) before presenting them to
|
|
the user. This is true regardless of the method of presentation to the OS
|
|
(OF device tree or
|
|
<emphasis>ibm,get-indices</emphasis> RTAS call). Relative to presentation
|
|
order, see also Requirement
|
|
<xref linkend="dbdoclet.50569347_56109"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_68142"
|
|
xrefstyle="select: labelnumber"/></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_56109">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para>If a platform
|
|
provides any 9007 indicators to the OS, then the following must be
|
|
true:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The platform must set the location code of each Identify (9007)
|
|
indicator and sensor (Enclosure, FRU, or connector) to be the location
|
|
code of the enclosure, FRU, or connector to which that indicator is
|
|
associated.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_68142">
|
|
<para>The System
|
|
Enclosure Identify (9007) indicator must be the first indicator in the
|
|
list of 9007 indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For every 9007 indicator, there must be a corresponding 9007
|
|
sensor which has the same index as the corresponding indicator.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para>A DR indicator (9002) must only be
|
|
provided to an OS if that particular OS image owns that resource and is
|
|
going to control the physical add, remove, and replace operations on the
|
|
FRU which is pointed to by that particular DR indicator.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
|
|
<listitem>
|
|
<para>If a PCI Hot Plug slot implements a single
|
|
physical amber indicator for use as both the PCI Hot Plug DR indicator
|
|
(for concurrent maintenance) and as the FRU Identify indicator, then that
|
|
indicator must be presented to a LoPAR compliant OS as both a 9002 and
|
|
9007 indicator.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_84242"
|
|
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
|
|
<listitem>
|
|
<para>All platforms must provide the
|
|
<emphasis role="bold"><literal>“ibm,fault-behavior”</literal></emphasis> and
|
|
<emphasis role="bold"><literal>“ibm,fru-9006-deactivate”</literal></emphasis> properties in
|
|
the
|
|
<literal>root</literal> node of the OF device tree, both with a value of
|
|
<literal>1</literal>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_88196">
|
|
|
|
<title>Lightpath User Interface (UI) Requirements</title>
|
|
<para>The base Lightpath architecture does not provide a User Interface
|
|
(UI), per se, when one considers a UI as being an interactive entity;
|
|
that is, where the user can input requests as well as just see the
|
|
faults. When enabling the Identify indicators of the Lightpath mode, a UI
|
|
is necessary. This architecture will call this the Lightpath UI. The
|
|
Lightpath UI is an interface between the Service Focal Point (SFP) and
|
|
the user of the SFP, and at a minimum, provides an interface to show
|
|
hidden Fault indicators (for example, see
|
|
<xref linkend="dbdoclet.50569347_25484" />). A slightly more
|
|
sophisticated Lightpath UI -- one with a General UI (GUI) such as an LCD
|
|
or general display like provided by IBM Director -- is required to
|
|
provide access to the Identify indicators.</para>
|
|
<para>Enablement of the Identify portion of Lightpath is important in
|
|
larger systems for reasons of deferred maintenance and guided
|
|
maintenance. In a system with deferred maintenance and Lightpath, many
|
|
Fault indicators may remain lit, requiring directed repair via an
|
|
Identify operation in order to see the component against which to do a
|
|
particular repair action. In addition, guided maintenance may be required
|
|
even if there is no failing component, to indicate to the user where to
|
|
plug or un-plug components or cables.</para>
|
|
<para>When a Lightpath UI is available, the platform does not display
|
|
logical Fault or Error Log on the physical indicators until a user
|
|
requests such a display of the indicators, with the exception that the
|
|
highest level roll-up indicators will be lit as a flag for the user to
|
|
use the Lightpath UI to identify the problem. The request to display
|
|
Fault and Error Log indicators may be made, for example, by pressing a
|
|
button or series of buttons, or by checking a check-box on a more
|
|
sophisticated Lightpath UI. The button(s) may be physical or may be on a
|
|
device like an LCD panel or other Service Focal Point (SFP) display, like
|
|
an IBM Director display.</para>
|
|
<para>
|
|
<xref linkend="dbdoclet.50569347_95432" /> defines an SFP as:
|
|
“…common point of control in the system for handling all
|
|
service actions which are not resolved otherwise (for example, via Fault
|
|
indicators).” SFPs may or may not exist lower end systems, and may
|
|
exhibit different levels of sophistication in larger systems. The
|
|
following are some (not all) system implementation examples:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>For simple systems, there may be no SFP and no Lightpath UI,
|
|
which means everything needs to be resolved by Fault indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For simple systems implementing Triple-S (see
|
|
<xref linkend="dbdoclet.50569347_25484" />), there may exist a simple SFP
|
|
with a simple Lightpath UI like one or more physical push-buttons. This
|
|
could be the System Error indicator with a physical button associated
|
|
with it, with the SFP being firmware underlying the button to communicate
|
|
with lower layers of firmware (for example, turn off FRU Fault indicators
|
|
as they are activated by the firmware, turn on all active FRU Faults
|
|
indicators on a button press). There may also be buttons for enabling the
|
|
lower layers of the Fault indicator hierarchy, and these buttons inform
|
|
the SFP firmware of the user’s request to display Fault indicators
|
|
on the physical indicators. In this case, the Lightpath UI is not
|
|
full-function and does not provide for enablement of the Identify
|
|
indicators. In this case, the firmware driving the Lightpath UI would use
|
|
the Lightpath UI base enablement (see
|
|
<xref linkend="dbdoclet.50569347_89428" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For intermediate systems, the Lightpath UI could be an LCD panel.
|
|
In this case, the firmware driving the Lightpath UI would use the
|
|
Lightpath UI base enablement (see
|
|
<xref linkend="dbdoclet.50569347_89428" />). The Triple-S UI is also
|
|
possible (see
|
|
<xref linkend="dbdoclet.50569347_25484" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For larger systems, the Lightpath UI could be part of a more
|
|
sophisticated interface, like IBM Director. This more sophisticated
|
|
interface would use the Lightpath UI base enablement (see
|
|
<xref linkend="dbdoclet.50569347_89428" />). The Triple-S UI is also
|
|
possible (see
|
|
<xref linkend="dbdoclet.50569347_25484" />).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<section xml:id="dbdoclet.50569347_89428">
|
|
<title>Lightpath UI Base Enablement Requirements</title>
|
|
<para>This section defines the base enablement requirements for all
|
|
Lightpath UI implementations. The Triple-S UI is one example of such a
|
|
Lightpath UI that uses the Lightpath UI Base Enablement. Other Lightpath
|
|
UIs are possible, and are not limited by this architecture.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry xml:id="dbdoclet.50569347_68068">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_89428"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Lightpath UI Base Enablement:</emphasis>
|
|
The platform must do all of the following:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Implement Lightpath Mode, as defined by this architecture,
|
|
lighting FRU Fault indicators or Error Log indicator associated with a
|
|
fault. Lightpath Mode includes the implementation of Identify
|
|
indicators.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_86534">
|
|
<para>If the SFP is
|
|
separate from the platform, then report to the SFP that the platform
|
|
implements the Lightpath UI Base Enablement (explicitly or implicitly).
|
|
(see implementation note, below)</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_16323">
|
|
<para>Whenever
|
|
possible, report all fault conditions which activate a FRU Fault
|
|
indicator or Error Log indicator, up to the SFP, with enough information
|
|
to allow determination by the SFP as to which FRU or Error Log indicators
|
|
are activated and the possible failing FRU(s). See the implementation
|
|
note, below, for the only exception cases allowed to this
|
|
requirement.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_17117">
|
|
<para>Accept commands
|
|
from the Service Focal Point (SFP) to put each indicator (FRU, Enclosure,
|
|
etc.), into the Off, Fault and Identify states (that is, the SFP can
|
|
control each indicator), and not report an activation or deactivation
|
|
error to the SFP if the SFP requests putting the indicator into a state
|
|
to which the indicator is already activated. See the implementation note,
|
|
below, for the only exception cases allowed to this requirement.</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_14345">
|
|
<para>Prevent multiple
|
|
reports of same error, whenever possible. (see implementation note,
|
|
below)</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Requirement
|
|
<xref linkend="dbdoclet.50569347_68068"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_86534"
|
|
xrefstyle="select: labelnumber"/> allows a SFP to manage multiple
|
|
platforms that implement different Service Indicator modes. Note that
|
|
this requirement can be implemented implicitly from other information
|
|
reported to the SFP (for example, machine type/model).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In Requirement
|
|
<xref linkend="dbdoclet.50569347_68068"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_16323"
|
|
xrefstyle="select: labelnumber"/> and
|
|
<xref linkend="dbdoclet.50569347_68068"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_17117"
|
|
xrefstyle="select: labelnumber"/>, acceptable reasons for not
|
|
being able to report errors to the SFP or have the SFP control the LEDs
|
|
may include:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Loss of communications between the component and the SFP.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A fault indicator that is entirely controlled by an OS, hardware,
|
|
or code, or an entity which is not in communications with the platform
|
|
firmware or the SFP.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Requirement
|
|
<xref linkend="dbdoclet.50569347_68068"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_14345"
|
|
xrefstyle="select: labelnumber"/> prevents continual
|
|
“blinking” of Fault indicator and the flooding of the
|
|
SFP’s event or error log.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_43836">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_89428"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Lightpath UI Base Enablement:</emphasis>
|
|
The Service Focal
|
|
Point (SFP) must exist and must do all of the following:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem xml:id="dbdoclet.50569347_42627">
|
|
<para>Receive and log
|
|
fault conditions reported by the platform. (see implementation note,
|
|
below)</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_37801">
|
|
<para>Turn off each
|
|
Fault indicator or Error Log indicator associated with a fault condition,
|
|
as soon as possible after the fault is reported, except as required to
|
|
remain on by user request user request (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_19733" />).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Accept direction from a user to show any faults on the Fault and
|
|
Error Log indicators (for example, see Requirement
|
|
<xref linkend="dbdoclet.50569347_19733" />).</para>
|
|
</listitem>
|
|
|
|
<listitem xml:id="dbdoclet.50569347_84423">
|
|
<para>If the SFP
|
|
contains a GUI (for example, an LCD display or a display like provided by
|
|
IBM Director), accept direction from a user to Identify a FRU or
|
|
connector for a service operation, and then turn off all activated FRU
|
|
Fault and Error Log indicators, unless otherwise directed by the user
|
|
(for example, by a check-box on the UI), and activate the FRU Identify
|
|
(blink), along with the normal FRU roll-up defined by the base Lightpath
|
|
Mode.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Relative to Requirements
|
|
<xref linkend="dbdoclet.50569347_43836"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_42627"
|
|
xrefstyle="select: labelnumber"/>, a SFP may (but is not
|
|
required to) do additional failure analysis, or may apply policy rules,
|
|
on the failure(s) reported, and by doing so may change or re-prioritize
|
|
the list of failures, such that the most likely failure(s) is (are)
|
|
different than the fault indicator(s) that were initially turned on by
|
|
the detecting entity. In which case, when the user requests that the
|
|
indicators be reactivated, a different set may be activated than those
|
|
that were originally activated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In simpler systems, it is expected that there may only be one
|
|
push-button implemented, and that would be associated with the highest
|
|
level Fault roll-up indicator. For systems, or collection of systems that
|
|
are managed by a SFP, which consist of many enclosures, it may be useful
|
|
for an implementation to implement several levels of buttons. For
|
|
example, a SFP that manages multiple systems may (at least) implement one
|
|
button per system.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_25484">
|
|
|
|
<title>See/Select/Service (Triple-S) User Interface
|
|
Requirements</title>
|
|
<para>The Triple-S UI architecture is built on top of the Lightpath UI
|
|
Base Enablement architecture, which is in turn built on top of the
|
|
Lightpath architecture. The Triple-S architecture is basically defined as
|
|
follows (see Requirements for specifics):</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Do not display Fault or Error Log on the physical indicators
|
|
until user pushes a button or series of buttons.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Except that the highest level roll-up for the Enclosure Fault
|
|
indicators and Error Log indicators will be activated if a lower level
|
|
one of the same type was activated.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>After seeing the highest level roll-up for Enclosure Fault or
|
|
Error Log being on, the user pushes one or more buttons (logical or
|
|
physical) associated with those, and then the user
|
|
<emphasis>Sees</emphasis> the Faults available for servicing.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The user
|
|
<emphasis>Selects</emphasis> the item they want to service, by observing
|
|
the FRU Faults and selecting they want to then Service.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The <emphasis>Selects</emphasis> part of Triple-S may also involve
|
|
activation of the FRU Identify indicator from the Lightpath UI.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The user completes the Service action on that component which was
|
|
selected.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Triple-S UI:</emphasis> The Lightpath UI Base Enablement
|
|
requirements must be met, as defined in
|
|
<xref linkend="dbdoclet.50569347_89428" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Triple-S UI:</emphasis> The platform must provide one or
|
|
more push-buttons (physical button, or logical on a GUI), each associated
|
|
with a set of Fault indicators or Error Log indicators which is (are) to
|
|
be used by the user to display (“show”) or not display
|
|
(“hide”) fault conditions on those group of indicators, as
|
|
defined by Requirement
|
|
<xref linkend="dbdoclet.50569347_19733" />.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry xml:id="dbdoclet.50569347_19733">
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
|
|
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Triple-S UI:</emphasis>
|
|
The Service Focal
|
|
Point (SFP) must accept direction from a user from a push-button
|
|
(physical or logical) press to show any fault conditions on, or hide all
|
|
fault conditions from, the physical indicators (FRU Faults and any
|
|
associated roll-up indicators for those indicators), which are associated
|
|
with the push-button (Fault or Error Log indicators). The fault
|
|
conditions must represent any open problems known by the SFP related to
|
|
the set of indicators associated with the push-button. The push of the
|
|
button must be a toggle operation, with each press either going from the
|
|
show state to the hide state or from the hide state to the show state,
|
|
based on the state prior to the push-button press. The platform must turn
|
|
off any indicators turned on by these push-button activations after a
|
|
pre-set period of time after the button activation, unless the pre-set
|
|
time is set to 0, in which case the indicators are left on until the
|
|
button is press again or until the platform determines they are no longer
|
|
needed to be on. (see implementation note, below).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_25484"
|
|
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
|
|
<listitem>
|
|
<para><emphasis role="bold">For the Triple-S UI:</emphasis> For more complex systems, and as
|
|
determined by the RAS requirements for those systems, the SFP must
|
|
implement a GUI (for example, an LCD or IBM Director display) and provide
|
|
the capability to activate the Identify indicators, as defined in
|
|
Requirement <xref linkend="dbdoclet.50569347_43836"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_84423"
|
|
xrefstyle="select: labelnumber"/>.</para>
|
|
|
|
<para>
|
|
<emphasis role="bold">Implementation Notes:</emphasis>
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Relative to Requirement
|
|
<xref linkend="dbdoclet.50569347_19733" />, a SFP may (but is not
|
|
required to) do additional failure analysis, or may apply policy rules,
|
|
on the failure(s) reported, and by doing so may change or re-prioritize
|
|
the list of failures, such that the most likely failure(s) is (are)
|
|
different than the fault indicator(s) that were initially turned on by
|
|
the detecting entity. In which case, when the user requests that the
|
|
indicators be reactivated, a different set may be activated than those
|
|
that were originally activated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Relative to Requirement
|
|
<xref linkend="dbdoclet.50569347_19733" />, the set of indicators
|
|
associated with a given push-button will normally be hierarchical, based
|
|
on the FRU Fault or Error Log roll-up path. For example, if a push-button
|
|
is associated with the Chassis Enclosure fault indictor, pressing that
|
|
button would toggle the show/hide state for all fault indicators within
|
|
that Chassis. Another example is pressing of a button associated with the
|
|
System Error roll-up indicator for a system, putting that system into the
|
|
“show” state could put that system basically into a Lightpath
|
|
(without Triple-S) mode, or “Lightpath Classic” mode. In this
|
|
latter example, it is not quite like previous implementations of
|
|
Lightpath because (1) service procedures may be different, (2) based on
|
|
Implementation note (a) the set of FRU Faults activated by the SFP may be
|
|
different than those activated by the entity detecting the error
|
|
originally, and (3) the Identify function can be used.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>Green Indicator Requirements</title>
|
|
<para>This chapter defines the platform requirements for green
|
|
indicators.</para>
|
|
<para>The usage of green indicators has been separated from the rest of
|
|
this chapter, because even though green indicators are used in some service
|
|
procedures (for example, to check for presence or absence of power on a
|
|
component or system), they are not to be used in lieu of amber FRU Fault
|
|
and Identify indicators. That is, they should supplement, not replace, the
|
|
amber indicators.</para>
|
|
<para>There are several exceptions to having all the green indicator
|
|
requirements in this chapter:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>The green indicator associated with a capacitor and pushbutton
|
|
implementation is specified in Requirement <xref linkend="dbdoclet.50569347_66721"
|
|
xrefstyle="select: nopage"/><xref linkend="dbdoclet.50569347_62866"
|
|
xrefstyle="select: labelnumber"/>.).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The capability to light all green indicators, as well as the amber
|
|
and blue indicators, for test purposes, is specified in Requirement
|
|
<xref linkend="dbdoclet.50569347_11274" />.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Unless indicated otherwise in this chapter, the blink rate for
|
|
green indicators, when they blink, is specified in Requirement
|
|
<xref linkend="dbdoclet.50569347_81809" />.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
|
|
<section xml:id="green_indicator_uses">
|
|
<title>Green Indicator Uses and General Requirements</title>
|
|
<para>Green indicators generally are not used for indicating a fault
|
|
condition.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="green_indicator_uses"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>A green indicator must not be used in
|
|
place of an amber Fault/Identify indicator, except when use of amber
|
|
Fault/Identify indicator is not possible, and in this exceptional case,
|
|
the green must be off or blinking to indicate the error condition.</para>
|
|
<para>
|
|
<emphasis role="bold">Implementation Note:</emphasis> Examples where a
|
|
green indicator
|
|
might be used instead of an amber Fault/Identify indicator are:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>In a power supply to indicate lack of AC power (green
|
|
off).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In the case where there is insufficient power to power the
|
|
component (green blinking).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="green_indicator_uses"
|
|
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
|
|
<listitem>
|
|
<para>There must exist a green power indicator
|
|
for every FRU that is to participate in concurrent maintenance
|
|
(“hot plug” operation), unless that FRU does not require the
|
|
removal of power to remove or insert that FRU.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_54601">
|
|
<title>Green Indicator States</title>
|
|
<para>This section attempts to capture the state requirements for all
|
|
usages of green indicators. If a state or usage is not specified, then
|
|
the user needs to get with the Architecture team for this architecture in
|
|
order to add or replace any state or usage of that state.</para>
|
|
|
|
<section xml:id="power_supply_green">
|
|
<title>Power Supply Green Indicators</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="power_supply_green"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>For power supply indicators, the
|
|
platform must implement the states defined in
|
|
<xref linkend="dbdoclet.50569347_83372" /> for each green indicator, and
|
|
must use those states only for the usages stated in
|
|
<xref linkend="dbdoclet.50569347_83372" />.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_83372">
|
|
<title>Power Supply Green Indicator States and Usage</title>
|
|
<?dbhtml table-width="80%" ?>
|
|
<?dbfo table-width="80%" ?>
|
|
<tgroup cols="2">
|
|
<colspec colname="c1" colwidth="40*" align="center" />
|
|
<colspec colname="c2" colwidth="60*" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Green Indicator State</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry align="center">
|
|
<para>
|
|
<emphasis role="bold">Usage</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Any not already covered in this table</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Consult with the xipSIA architecture team for the proper
|
|
usage/behavior.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>For the input power indicator: no input power.</para>
|
|
<para>For the output power indicator: no output power.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>On</para>
|
|
</entry>
|
|
<entry>
|
|
<para>For the input power indicator: input power good.</para>
|
|
<para>For the output power indicator: output power good.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Slow blink (1 Hz, 50% duty cycle)</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Power supply (or supplies) are in the standby state. A
|
|
power supply must not blink its green output power indicator
|
|
unless that particular supply is in the standby state.</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="dbdoclet.50569347_21912">
|
|
<title>System Power Green Indicators</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569347_21912"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>For system power indicators, the
|
|
platform must implement the states defined in
|
|
<xref linkend="dbdoclet.50569347_73050" /> for each green indicator, and
|
|
must use those states only for the usages stated in
|
|
<xref linkend="dbdoclet.50569347_73050" />.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_73050">
|
|
<title>System Power Green Indicator States and Usage</title>
|
|
<?dbhtml table-width="80%" ?>
|
|
<?dbfo table-width="80%" ?>
|
|
<tgroup cols="2">
|
|
<colspec colname="c1" colwidth="40*" align="center" />
|
|
<colspec colname="c2" colwidth="60*" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Green Indicator State</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry align="center">
|
|
<para>
|
|
<emphasis role="bold">Usage</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Any not already covered in this table</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Consult with the xipSIA architecture team for the proper
|
|
usage/behavior.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>System is off (no standby power).</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>On</para>
|
|
</entry>
|
|
<entry>
|
|
<para>System is on (operational state).</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Fast blink (4 Hz, 50% duty cycle)</para>
|
|
</entry>
|
|
<entry>
|
|
<para>A determination is being made as to whether the system
|
|
(for example, a Blade in a Blade System) has enough power
|
|
available to it, in order to power up, or a determination has
|
|
already been made that there is not enough power, and the
|
|
indicator remains in this state.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Slow blink (1 Hz, 50% duty cycle)</para>
|
|
</entry>
|
|
<entry>
|
|
<para>System is in the standby power state.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Fade-in/fade-out cycling of the power LED as done in
|
|
various PC and notebook manufacturers:</para>
|
|
<para>the period of this fade-in/fade-out cycle is 2 seconds,
|
|
gradually ranging from fully on to fully off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Systems that support system-level sleep states (such as
|
|
the S3 sleep state) must use this state as a way to indicate
|
|
the system is sleeping but still powered on.</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="hdd_green">
|
|
<title>HDD Green Indicators</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="hdd_green"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>For Hard Disk Drives (HDD) the platform
|
|
must implement the states defined in
|
|
<xref linkend="dbdoclet.50569347_38629" /> for each green indicator, and
|
|
must use those states only for the usages stated in
|
|
<xref linkend="dbdoclet.50569347_38629" />.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_38629">
|
|
<title>HDD Green Indicator States and Usage</title>
|
|
<?dbhtml table-width="80%" ?>
|
|
<?dbfo table-width="80%" ?>
|
|
<tgroup cols="2">
|
|
<colspec colname="c1" colwidth="40*" align="center" />
|
|
<colspec colname="c2" colwidth="60*" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Green Indicator State</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry align="center">
|
|
<para>
|
|
<emphasis role="bold">Usage</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Any not already covered in this table</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Consult with the xipSIA architecture team for the proper
|
|
usage/behavior.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Platform specific.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>On</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Platform specific.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Flickering (randomly blinking)</para>
|
|
</entry>
|
|
<entry>
|
|
<para>HDD activity (HDD is powered on and is being
|
|
used).</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="other_component_green">
|
|
<title>Other Component/FRU Green Indicators</title>
|
|
<para>This section attempts to capture the state requirements for usages
|
|
of green indicators that are not specifically called out as special cases
|
|
elsewhere in
|
|
<xref linkend="dbdoclet.50569347_54601" />. To reiterate what was
|
|
specified, above: if a state or usage is not specified, then the user
|
|
needs to get with the Architecture team for this architecture in order to
|
|
add or replace any state or usage of that state.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="other_component_green"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>For FRUs or components other than
|
|
specific ones specified elsewhere in
|
|
<xref linkend="dbdoclet.50569347_54601" />, which require power
|
|
indicators, the platform must implement the states defined in
|
|
<xref linkend="dbdoclet.50569347_66324" /> for each green indicator, and
|
|
must use those states only for the usages stated in
|
|
<xref linkend="dbdoclet.50569347_66324" />.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_66324">
|
|
<title>Sub-Unit (Component) Green Indicator States and
|
|
Usage</title>
|
|
<?dbhtml table-width="80%" ?>
|
|
<?dbfo table-width="80%" ?>
|
|
<tgroup cols="2">
|
|
<colspec colname="c1" colwidth="40*" align="center" />
|
|
<colspec colname="c2" colwidth="60*" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Green Indicator State</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry align="center">
|
|
<para>
|
|
<emphasis role="bold">Usage</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Any not already covered in this table</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Consult with the xipSIA architecture team for the proper
|
|
usage/behavior.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Component/FRU is powered off and/or is not in
|
|
operation.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>On</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Component/FRU is powered on.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Blink 1 Hz, 50% duty cycle</para>
|
|
</entry>
|
|
<entry>
|
|
<para>(Optional) Component/FRU is in transition to the off
|
|
state. Note that although this is an optional state, it is
|
|
highly recommended (for Human Factors reasons) for cases where
|
|
it takes awhile to power off the component (for example, for
|
|
hardware like a Blade in a Blade System that has to be quiesced
|
|
before powering off).</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
<section xml:id="communication_link_green">
|
|
<title>Communication Link Green Indicators</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><emphasis role="bold">R1-<xref linkend="communication_link_green"
|
|
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
|
|
<listitem>
|
|
<para>For communication links, the platform
|
|
must implement the states defined in
|
|
<xref linkend="dbdoclet.50569347_90668" /> for each green indicator, and
|
|
must use those states only for the usages stated in
|
|
<xref linkend="dbdoclet.50569347_90668" />.</para>
|
|
<para> </para>
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50569347_90668">
|
|
<title>Communication Link Green Indicator States and
|
|
Usage</title>
|
|
<?dbhtml table-width="80%" ?>
|
|
<?dbfo table-width="80%" ?>
|
|
<tgroup cols="2">
|
|
<colspec colname="c1" colwidth="40*" align="center" />
|
|
<colspec colname="c2" colwidth="60*" />
|
|
<thead>
|
|
<row>
|
|
<entry>
|
|
<para>
|
|
<emphasis role="bold">Green Indicator State</emphasis>
|
|
</para>
|
|
</entry>
|
|
<entry align="center">
|
|
<para>
|
|
<emphasis role="bold">Usage</emphasis>
|
|
</para>
|
|
</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody valign="middle" >
|
|
<row>
|
|
<entry>
|
|
<para>Any not already covered in this table</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Consult with the xipSIA architecture team for the proper
|
|
usage/behavior.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Off</para>
|
|
</entry>
|
|
<entry>
|
|
<para>No link connection or link connected but no
|
|
activity.</para>
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry>
|
|
<para>Flickering (randomly blinking)</para>
|
|
</entry>
|
|
<entry>
|
|
<para>Communication link activity.</para>
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
|
|
</section>
|
|
</chapter>
|