[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freeipmi-devel] NUT PSU/IPMI driver using FreeIPMI (was: in need of
Re: [Freeipmi-devel] NUT PSU/IPMI driver using FreeIPMI (was: in need of guidance...)
Wed, 20 Jul 2011 16:47:28 -0700
On Wed, 2011-07-20 at 13:29 -0700, Arnaud Quette wrote:
> Hey Al,
> 2011/7/19 Albert Chu <address@hidden>
> > (...)
> > I assuming you mean libipmidetect? libipmidetect is
> > 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
> > over the network.
> > but for now, I've released a preliminary version of
> > which supports only FRU info retrieval.
> > It is available in NUT trunk, includes an m4 macro (ready
> > pkgconfig, but currently using AC_CHECK_HEADERS/FUNCS), and
> > 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
> > to an FRU?
> > Ie, I've found that the first PSU is ID 2. But how do I know
> > sensor X is the one attached to this board?
> Whew. It's not going to be easy. The current FRU format does
> support information to point you to the specific sensor
> 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
> probably work for many motherboards. However, there is no
> 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
> 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
> 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 ;-)
> > - the things I'm using to parse FRU (like
> > 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
> > 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
> 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
> 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
> > 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?
> 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.
High Performance Systems Division
Lawrence Livermore National Laboratory