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.
Linux-Architecture-Reference/Error Handling/app_service_indicators.xml

4169 lines
196 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016 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.
-->
<appendix 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 &#8220;indicators&#8221; are referred to as
&#8220;LEDs&#8221; 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>&#8220;Enclosure&#8221;, 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 (&#8220;appliance&#8221; 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
&#8220;remind&#8221; 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
&#8220;Identify&#8221; or &#8220;Identify indicator&#8221;.</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="LoPAR.Virtualization" />. This indicator is amber
<footnote xml:id="pgfId-630879">
<para>The term &#8220;amber&#8221; 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 &#8220;virtual&#8221; does not appear before
&#8220;Error Log&#8221;, 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 &#8220;activate&#8221; means, see
<xref linkend="dbdoclet.50569347_12130" />.</para>
</footnote>at the user&#8217;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&#8217; 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&#8217; 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&#8217;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&#8217;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&#8217;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>&#160;</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*" />
<colspec colname="c2" colwidth="33*" />
<colspec colname="c3" colwidth="33*" />
<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>
<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&#8217;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&#8217;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
&#8220;unit,&#8221; but a unit is not necessarily a drawer and a drawer
is not necessarily a unit, so the term &#8220;unit&#8221; 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 &#8220;intermediate&#8221; level or
&#8220;secondary&#8221; 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 &#8220;group&#8221; 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>&#8220;ibm,service-indicator-mode&#8221;</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
&#8220;<emphasis role="bold">For Lightpath Mode platforms:</emphasis>&#8221;
only apply to
Lightpath Mode platforms. Requirements which are prefaced by
&#8220;<emphasis role="bold">For Guiding Light Mode platforms:</emphasis>&#8221;
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 &#8220;off&#8221; and &#8220;on,&#8221; 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 &#8220;very low end servers&#8221; 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 &#8220;off&#8221; and &#8220;blink,&#8221; 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 &#8220;off&#8221;
and &#8220;blink&#8221; 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 &#8220;off&#8221; and &#8220;on&#8221; 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 &#8220;off,&#8221; &#8220;blink,&#8221; and
&#8220;on&#8221; 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 &#8220;off,&#8221;
&#8220;on,&#8221; and &#8220;blip&#8221;.</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 &#8220;explicit
trust&#8221; 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 &#8220;no such indicator&#8221; 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
&#8220;blip&#8221; rate for the Enclosure Fault indicators when in the
&#8220;remind&#8221; 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 &#8220;blink&#8221; and Fault state as
&#8220;on&#8221;).</para>
</listitem>
<listitem>
<para><emphasis role="bold">For Guiding Light Mode platforms:</emphasis>
The Identify state
must be supported, and the indicator must activate (&#8220;blink&#8221;)
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>&#8220;ibm,fault-behavior&#8221;</literal></emphasis> and
<emphasis role="bold"><literal>&#8220;ibm,fru-9006-deactivate&#8221;</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:
&#8220;&#8230;common point of control in the system for handling all
service actions which are not resolved otherwise (for example, via Fault
indicators).&#8221; 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&#8217;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
&#8220;blinking&#8221; of Fault indicator and the flooding of the
SFP&#8217;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 (&#8220;show&#8221;) or not display
(&#8220;hide&#8221;) 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
&#8220;show&#8221; state could put that system basically into a Lightpath
(without Triple-S) mode, or &#8220;Lightpath Classic&#8221; 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
(&#8220;hot plug&#8221; 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>&#160;</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*" />
<colspec colname="c2" colwidth="60*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Green Indicator State</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<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>&#160;</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*" />
<colspec colname="c2" colwidth="60*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Green Indicator State</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<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>&#160;</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*" />
<colspec colname="c2" colwidth="60*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Green Indicator State</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<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>&#160;</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*" />
<colspec colname="c2" colwidth="60*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Green Indicator State</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<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>&#160;</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*" />
<colspec colname="c2" colwidth="60*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Green Indicator State</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Usage</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<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>
</appendix>