[Nut-upsdev] NUT PSU/IPMI driver using FreeIPMI (was: [Freeipmi-devel] in need of guidance...)

[Albert Chu]

Hey Arnaud,

On Wed, 2011-07-20 at 13:29 -0700, Arnaud Quette wrote:
> Hey Al,
> 
> 2011/7/19 Albert Chu <chu11 at llnl.gov>
>         > (...)
>         >         I assuming you mean libipmidetect?  libipmidetect is
>         primarily
>         >         used for
>         >         detecting if ipmi over LAN exists, not for
>         identifying any
>         >         particular
>         >         component.  Not sure if it would be any use for you.
>         >
>         > understood. we may have needs in the future, to do the same
>         detection
>         > over the network.
>         > but for now, I've released a preliminary version of
>         'nut-ipmipsu',
>         > which supports only FRU info retrieval.
>         > It is available in NUT trunk, includes an m4 macro (ready
>         for
>         > pkgconfig, but currently using AC_CHECK_HEADERS/FUNCS), and
>         an
>         > abstracted IPMI implementation (only provided by FreeIPMI).
>         >
>         > I still have to had the sensor's info, and have 2 questions
>         for you:
>         > - is there a way to automatically determine which sensor is
>         attached
>         > to an FRU?
>         > Ie, I've found that the first PSU is ID 2. But how do I know
>         that
>         > sensor X is the one attached to this board?
>         
>         
>         
>         Whew.  It's not going to be easy.  The current FRU format does
>         not
>         support information to point you to the specific sensor
>         record.
>  
> that's sad, since to an IPMI newbie like me, such a reference seems
> obviously required and mandatory.
> I was pretty sure that I was missing something around the sensor owner
> ID, order of appearance (ie the 1rst PSU FRU with the first PSU
> sensor) or alike.
> 
>         If you tried to match power supply names (e.g. "PS 1"), that
>         would
>         probably work for many motherboards.  However, there is no
>         guarantee
>         that a motherboard would ensure the FRU power supply name
>         matches the
>         sensor one.  In fact, I looked at one motherboard I have here,
>         and they
>         don't match.
>         
>         I *think* there is another way, but it gets complicated.  You
>         start to
>         dig into a lot of IPMI specifics and nuances (which most of
>         the FreeIPMI
>         libraries naturally try to hide).
>         
>         If you take a look at the original ipmi-fru code,
>         run_cmd_args() has a
>         loop that loops through the sensor data repository (where
>         records on
>         each sensor are kept).  That's where ipmi-fru finds the device
>         IDs (e.g.
>         ID 2) to look through.  In the FRU SDR entry, there is another
>         field for
>         an fru_entity_id and fru_entity_instance (see
>         freeipmi/templates/ipmi-sdr-record-format-templates.h).  That
>         entity ID
>         and instance could be mapped to the entity-id/instance for the
>         sensor
>         SDR records (in combination w/ checking the sensor-type and a
>         few other
>         fields).  This will probably work on most motherboards.
>         
>         However, this later part is quite complicated.  You'd be
>         scanning/parsing the SDR manually to find these little bits
>         b/c it isn't
>         normally available in libipmimonitoring.
>         
>         This is such a unique case, I doubt it'd be something that
>         would "fit"
>         along with any of the current freeipmi libraries.  I can help
>         you write
>         something for NUT that is specific for your needs though.  It
>         can scan
>         for FRU entries, then perhaps scan for sensor entries, and
>         give you back
>         record IDs??  Which can subsequently be pumped into
>         libipmimonitoring
>         for the specific sensors??
> 
> I understand ;-)
> do you think it involves duplicating a large chunk of the libs?

I doubt it would be a tremendous amount of code.

> I'm trying to weight the pros and cons, and still consider a simple
> default (that works enough) with override params for nut-ipmipsu.
> ie, default to the order of appearance (I still have to "validate"
> this), and provide psuID and sensorID params to force targets if this
> doesn't work.
>
> your help is still welcome, obviously. so thanks for your offer ;-)

No prob.

>         > - the things I'm using to parse FRU (like
>         ipmi_fru_parse_ctx_create)
>         > and other things (lie ipmi_ctx_find_inband) are not
>         available in
>         > 0.7.17 (the base I'm working on, Ubuntu up to 11.04).
>         > I've dug quickly the ChangeLog, but was not able to identify
>         clearly
>         > when these functions were added.
>         > What is the minimal FreeIPMI required?
>         
>         
>         Most of these were added in FreeIPMI 0.8.1.  Many of the core
>         functions
>         were initially only in tools and in FreeIPMI 0.8.1 they were
>         "library-ized".  There could be an odd-ball function here or
>         there that
>         were added in FreeIPMI 1.0.1, but I think you'd be safe with
>         0.8.1.
>  
> thanks for these hints.
> I'll do some compilation testing to validate the final code.
> 
> 
>         >
>         >         >
>         >         >         Hopefully that's enough to get you going.
>          LMK if
>         >         you need
>         >         >         some help
>         >         >         deciphering the code more.
>         >         >
>         >         > this should not be needed, but thanks for your
>         kind
>         >         proposition.
>         >         >
>         >         > but you should probably publish this code in
>         examples/, with
>         >         a name
>         >         > like "simple-ipmi-fru.c" or alike, and highlight
>         this code
>         >         sample a
>         >         > bit.
>         >
>         >
>         >         That's the plan eventually :P
>         >
>         > so I've a minor patch for you (attached) ;)
>         > it fixes indentation (replace tabs by spaces), and a typo on
>         > 'frequenc*e*y'.
>         > it may also be interesting to give the example compilation
>         line in the
>         > file header...
>         
>         
>         Somehow the patch came to me as 0 byte in length.  Could you
>         try again?
> 
> strange!
> I've checked my sent mail and it was 18 Kb.
> anyway, it's attached again.

I got it this time.  Yeah, the tabbing issue was me hacking together an
example too quickly.  But the typo I can put into the mainline code.

> btw, have you been able to read my "improvement ideas" mail?

Yeah, I read it awhile back.  Like many projects, there is a bit of a
momentum thing going on.  I sort of logged it to memory as something for
the future to consider.

Al

> cheers,
> Arno
> 
-- 
Albert Chu
chu11 at llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory