Re: [Freeipmi-users] Mixed assertion/deassertion problems on Sun X4150

[Al Chu]

Hey Rob,

That's interesting.  You updated from ELOM to ILOM, and new sensors
showed up?  If that's the case, there could be a bug in the firmware.
In the case where a sensor is not present, the sensor reading should
report back that the sensor is unavailable.  ipmimonitoring would
subsequently not read/interpret that sensor.  You may wish to ping Sun
on this (or maybe someone on the mailing list will respond :-)

Al

On Fri, 2009-05-15 at 21:43 +0100, Rob O'Connor wrote:
> Many thanks for your help! I was checking out sensor configs and
> editing and getting nowhere, and really thinking I must be missing
> something obvious - at least I'm not going totally mad!
> This particular case with the X4150 might be slightly unusual in the
> service processor was upgraded from an ELOM to an ILOM - and I'm not
> quite sure what power supply sensors were previously available before
> the update or whether the ELOM->ILOM update introduced some kind of
> edge case where it ended up with 2 sets of sensors with conflicting
> assertion. I've also got a bunch of X4100s which just have these in
> the Power Supply group (a subset of those found on the X4150s):
> 
> 29 | PS0/VINOK | Power Supply | Warning | N/A | 'State Asserted'
> 30 | PS0/PWROK | Power Supply | Warning | N/A | 'State Asserted'
> 43 | PS1/VINOK | Power Supply | Warning | N/A | 'State Asserted'
> 44 | PS1/PWROK | Power Supply | Warning | N/A | 'State Asserted'
> and this was my original problem - they throw a Warning for a 'State
> Asserted'. I'd hacked it and swapped the assertion in the sensor
> config file, and copied the new sensor config around and then realised
> the X4150s had the additional sensors which didn't quite fit. 
> So I suppose my real problem is with the 4 sensors above, and ideally
> I'd love to fix the status on them.
> 
> Rob.
> 
> Al Chu wrote: 
> > Hi Rob,
> > 
> > Argh!  I was afraid some vendor would do something like this eventually.
> > Having the same "style" sensors report states/events in non-consistent
> > manners.  I will have to think of a way to deal with this in the future.
> > As for your question ...
> > 
> >   
> > > I've been trying to figure if I can get ipmimonitoring to simply not 
> > > report some sensors (e.g the PS*/*_FAULT) ones above - but can't 
> > > figure how to do this. Is it possible?
> > >     
> > 
> > There is a --groups and --sensors option for ipmimonitoring where you
> > can specifically list which sensors/groups you want to see.  You can
> > configure the default list of groups into the freeipmi.conf file to make
> > it default to a certain output if that makes things easier for you [1].
> > 
> > Unfortunately, these are "show me this stuff" options, not "exclude this
> > stuff" options.  So you'll have to list all the groups/sensors you want.
> > 
> > Longer term (it's now on my TODO), it might be good if I create a
> > "--exclude-groups" and "--exclude-sensors" options, that can eliminate
> > sensors to list.
> > 
> > Hope that answers your question.  And thanks for e-mailing about this.
> > Now I see a new good option I should put into ipmi-sensors and
> > ipmimonitoring.
> > 
> > Al
> > 
> > [1] There's a typo in the freeipmi.conf file that'll be fixed soon.  You
> > separate groups by spaces, not commas.
> > 
> > On Fri, 2009-05-15 at 08:03 -0700, ocoro02 wrote:
> >   
> > > Hi Folks - I'm using FreeIPMI 0.7.8 on Solaris 10 on some Sun X4150 
> > > servers -
> > > these have had their Eloms updated to be Iloms running (from memory)
> > > 2.0.2.10 of the Ilom firmware.
> > > 
> > > With ipmimonitoring for the Power_Supply group I see:
> > > 
> > > # ipmimonitoring  | grep "Power Supply"
> > > 29 | PS0/VINOK | Power Supply | Warning | N/A | 'State Asserted'
> > > 30 | PS0/PWROK | Power Supply | Warning | N/A | 'State Asserted'
> > > 31 | PS0/CUR_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 32 | PS0/VOLT_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 33 | PS0/FAN_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 34 | PS0/TEMP_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 43 | PS1/VINOK | Power Supply | Warning | N/A | 'State Asserted'
> > > 44 | PS1/PWROK | Power Supply | Warning | N/A | 'State Asserted'
> > > 45 | PS1/CUR_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 46 | PS1/VOLT_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 47 | PS1/FAN_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 48 | PS1/TEMP_FAULT | Power Supply | Nominal | N/A | 'State Deasserted'
> > > 
> > > You see the problem? The '*OK' sensors are asserted, but in Warning 
> > > state. 
> > > Unfortunately I can't flip assertion in ipmi_monitoring_sensors.conf - i.e
> > > like this:
> > > 
> > > IPMI_Power_Supply_State_Deasserted     Critical
> > > IPMI_Power_Supply_State_Asserted       Nominal
> > > 
> > > because the '*_FAULT' sensors will then be in Critical.  
> > > 
> > > I've been trying to figure if I can get ipmimonitoring to simply not 
> > > report
> > > some sensors (e.g the PS*/*_FAULT) ones above - but can't figure how to do
> > > this. Is it possible?
> > >     
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory