Matty wrote:
> On Dec 12, 2007 12:38 PM, Eric Schrock <[EMAIL PROTECTED]> 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-discuss@opensolaris.org

Reply via email to