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

[Arnaud Quette]

Hey Al,

2011/7/21 Albert Chu <chu11 at llnl.gov>

> 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.
>

glad to hear this confirmation :)


> > 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.
>

as per your above comment, I'm interested in a code sample if you have a bit
of time...


> >         > - 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.
>

ok, thanks.


> > 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.
>

perfect, I just wanted to be sure that you at least had a ticket in mind ;-)

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110727/c85d3ffe/attachment-0001.html>