Setting fault LEDs

On Dec 12, 2007 12:38 PM, Eric Schrock <eric.schrocksun.com> wrote:
> On Wed, Dec 12, 2007 at 09:22:07AM -0800, Richard
Elling wrote:
> >
> > For Sun systems, we have 3 LEDs on the drives:
> > 1. Ready to remove (blue)
> > 2. Service required (amber)
> > 3. OK/Activity (green)
> >
> > So there must be a way to set the ready to remove
LED from Solaris.
> > In the old days, we could use luxadm(1m).  Does
that still work, or is
> > there some new equivalent?
> >
>
> For x86 systems, you can use ipmitool to manipulate the
led state
> (ipmitool sunoem led ...).   On older galaxy systems,
you can only set the
> fail LED ('io.hdd0.led'), as the ok2rm LED is not
physically connected
> to anything.  On newer systems, you can set both the
'fail' and 'okrm'
> LEDs.  You cannot change the activity LED except by
manually sending the
> 'set sensor reading' IPMI command (not available via
impitool).
>
> For external enclosures, you'll need a SES control
program.
>
> Both of these problems are being worked on under the
FMA sensor
> framework to create a unified view through libtopo. 
Until that's
> complete, you'll be stuck using ad hoc methods.

Eric Schrock brought up an interesting point on zfs-discuss 
(see
above). Are there any plans (from my understanding, the
current agents
don't provide this capability) to introduce an agent to set
fault LEDs
when FMA diagnoses a hardware fault? For large data centers,
this
would be incredibly useful.

Thanks,
- Ryan
-- 
UNIX Administrator
http://prefetch.net
_______________________________________________
fm-discuss mailing list
fm-discussopensolaris.org

Matty wrote:
> On Dec 12, 2007 12:38 PM, Eric Schrock
<eric.schrocksun.com> wrote:
>> On Wed, Dec 12, 2007 at 09:22:07AM -0800, Richard
Elling wrote:
>>> For Sun systems, we have 3 LEDs on the drives:
>>> 1. Ready to remove (blue)
>>> 2. Service required (amber)
>>> 3. OK/Activity (green)
>>>
>>> So there must be a way to set the ready to
remove LED from Solaris.
>>> In the old days, we could use luxadm(1m).  Does
that still work, or is
>>> there some new equivalent?
>>>
>> For x86 systems, you can use ipmitool to manipulate
the led state
>> (ipmitool sunoem led ...).   On older galaxy
systems, you can only set the
>> fail LED ('io.hdd0.led'), as the ok2rm LED is not
physically connected
>> to anything.  On newer systems, you can set both
the 'fail' and 'okrm'
>> LEDs.  You cannot change the activity LED except by
manually sending the
>> 'set sensor reading' IPMI command (not available
via impitool).
>>
>> For external enclosures, you'll need a SES control
program.
>>
>> Both of these problems are being worked on under
the FMA sensor
>> framework to create a unified view through libtopo.
 Until that's
>> complete, you'll be stuck using ad hoc methods.
> 
> Eric Schrock brought up an interesting point on
zfs-discuss  (see
> above). Are there any plans (from my understanding, the
current agents
> don't provide this capability) to introduce an agent to
set fault LEDs
> when FMA diagnoses a hardware fault? For large data
centers, this
> would be incredibly useful.

Why yes, there are plans.  As part of the phase I sensor
project, we 
also introduced the notion of an indicator that can be
expressed via 
libtopo.  I have a prototype of the libtopo changes that I
handed off to 
a colleague here at Sun.  He is working on integrating an
IPMI backend 
such FMA agents simply call a libtopo interface to light the
'fail' (or 
whatever) LED as Eric eluded to.  Once that's in place, we
could modify 
existing fmd agents or create new ones responsible for
manipulating the 
LEDs.

Cindi
_______________________________________________
fm-discuss mailing list
fm-discussopensolaris.org