[Nut-upsdev] NUT PSU/IPMI driver using FreeIPMI (was: [Freeipmi-devel] in need of guidance...)
Albert Chu
chu11 at llnl.gov
Tue Jul 19 17:25:52 UTC 2011
Hey Arnaud,
On Tue, 2011-07-19 at 04:35 -0700, Arnaud Quette wrote:
> Hi Al,
>
> 2011/7/1 Albert Chu <chu11 at llnl.gov>
> Hi Arnaud,
>
>
> On Fri, 2011-07-01 at 01:56 -0700, Arnaud Quette wrote:
> > Hi Al,
> >
> > (FYI, I cc'ed the NUT developers list for info)
> >
> > 2011/6/30 Albert Chu <chu11 at llnl.gov>
> > Hi Arnaud,
> >
> > On Tue, 2011-06-28 at 12:19 -0700, Arnaud Quette
> wrote:
> >
> > > Hi Al,
> > >
> > > 2011/6/28 Albert Chu <chu11 at llnl.gov>
> > > On Tue, 2011-06-28 at 02:28 -0700, Arnaud
> Quette
> > wrote:
> > > (...)
> > > > I'm *very* interested in!
> > > > this could even serve as a simple
> example, shipped
> > in the
> > > examples/
> > > > directory.
> > >
> > >
> > >
> > > Unfortunately, it will require knowledge
> of the IPMI
> > > protocol/specification, which makes it
> difficult
> > (and why I
> > > probably
> > > never bothered with an example).
> > >
> > > Everything is in the ipmi-fru and
> ipmi-sensors
> > tools, however
> > > I imagine
> > > a lot of the options, permutations of
> things, IPMI
> > spec
> > > details, etc. is
> > > what's making it confusing.
> > >
> > > Give me some time, and I'll try to
> "whittle" the
> > ipmi-fru and
> > > ipmi-sensors tools into a far simpler
> example that
> > can give
> > > you a basis
> > > for what you're trying to accomplish.
> > >
> > > sure, thanks a lot for your much appreciated
> proposition.
> > > since I have some hard deadlines, do you have any
> > approximate idea on
> > > when you'd be able to release this?
> >
> >
> > Attached is a simplified ipmi-fru that you can
> hopefully use
> > to extract
> > the FRU information you seek. "gcc
> ipmi-fru-example.c
> > -lfreeipmi" is
> > all you need to do. I took out a lot of stuff, and
> there a
> > number of
> > special cases not handled. It may not work for all
> > motherboards, but is
> > a good place to start.
> >
> > awesome, thanks a lot Al!
> > I'm starting to see the light, though I've not yet read the
> code
> > thoroughly...
> >
> > I just have to check (maybe with libdetect) how to identify
> PSU, but I
> > already got the following data by modifying
> > ipmi_fru_parse_open_device_id() to specify a known PSU ID:
> >
> > FRU Board Language: English
> > FRU Board Manufacturing Date/Time: 01/05/11 - 08:51:00
> > FRU Board Manufacturer: DELL
> > FRU Board Product Name: PWR SPLY,717W,RDNT
> > FRU Board Serial Number: CN179721130031
> > FRU Board Part Number: 0RN442A01
> >
> > FRU Power Supply Overall Capacity: 717 Watts
> > FRU Power Supply Peak VA: 0 VA
> > FRU Power Supply Max Inrush Current: 0 Amps
> > FRU Power Supply Inrush Interval: 0 ms
> > FRU Power Supply Low End Input Voltage 1: 90000 mV
> > FRU Power Supply High End Input Voltage 1: 264000 mV
> > FRU Power Supply Low End Input Voltage 2: 0 mV
> > FRU Power Supply High End Input Voltage 2: 0 mV
> > FRU Power Supply Low End Acceptable Frequencey: 47 Hz
> > FRU Power Supply High End Acceptable Frequencey: 63 Hz
> > FRU Power Supply A/C Dropout Tolerance: 0 ms
> > FRU Power Supply Predictive Fail Support: No
> > FRU Power Supply Power Factor Correction Supported: No
> > FRU Power Supply AutoSwitch Supprt: Yes
> > FRU Power Supply Hot Swap Support: Yes
> > FRU Power Supply Peak Capacity: 0 Watts
> > FRU Power Supply Hold Up Time: 0 s
> > FRU Power Supply Voltage 1: 12V
> > FRU Power Supply Voltage 2: 12V
> > FRU Power Supply Total Combined Wattage: 0 Watts
> >
> > As for sensors, I figured you would probably want to
> use
> > libipmimonitoring, since it's at a much higher
> level. I would
> > suggest
> > looking at the ipmimonitoring-sensors.c file.
> >
> > indeed, that's what I understood.
> > as told above, I just got to check libdetect for PSU
> identification,
> > then everything should be alright.
>
>
> 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.
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??
> - 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.
>
> >
> > 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?
Al
> cheers,
> Arnaud
> --
> Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
> Network UPS Tools (NUT) Project Leader -
> http://www.networkupstools.org/
> Debian Developer - http://www.debian.org
> Free Software Developer - http://arnaud.quette.free.fr/
>
--
Albert Chu
chu11 at llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
More information about the Nut-upsdev
mailing list