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

[Arnaud Quette]

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'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 ;-)

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

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

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110720/32213324/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fru-ex-fix.patch
Type: application/mbox
Size: 18236 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110720/32213324/attachment-0001.bin>