Hey Al,<br><br><div class="gmail_quote">2011/7/19 Albert Chu <span dir="ltr"><<a href="mailto:chu11@llnl.gov" target="_blank">chu11@llnl.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> (...)<br>
> I assuming you mean libipmidetect? libipmidetect is primarily<br>
> used for<br>
> detecting if ipmi over LAN exists, not for identifying any<br>
> particular<br>
> component. Not sure if it would be any use for you.<br>
><br>
> understood. we may have needs in the future, to do the same detection<br>
> over the network.<br>
> but for now, I've released a preliminary version of 'nut-ipmipsu',<br>
> which supports only FRU info retrieval.<br>
> It is available in NUT trunk, includes an m4 macro (ready for<br>
> pkgconfig, but currently using AC_CHECK_HEADERS/FUNCS), and an<br>
> abstracted IPMI implementation (only provided by FreeIPMI).<br>
><br>
> I still have to had the sensor's info, and have 2 questions for you:<br>
> - is there a way to automatically determine which sensor is attached<br>
> to an FRU?<br>
> Ie, I've found that the first PSU is ID 2. But how do I know that<br>
> sensor X is the one attached to this board?<br>
<br>
</div></div><br>Whew. It's not going to be easy. The current FRU format does not<br>
support information to point you to the specific sensor record.<br></blockquote><div> <br>that's sad, since to an IPMI newbie like me, such a reference seems obviously required and mandatory.<br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
If you tried to match power supply names (e.g. "PS 1"), that would<br>
probably work for many motherboards. However, there is no guarantee<br>
that a motherboard would ensure the FRU power supply name matches the<br>
sensor one. In fact, I looked at one motherboard I have here, and they<br>
don't match.<br>
<br>
I *think* there is another way, but it gets complicated. You start to<br>
dig into a lot of IPMI specifics and nuances (which most of the FreeIPMI<br>
libraries naturally try to hide).<br>
<br>
If you take a look at the original ipmi-fru code, run_cmd_args() has a<br>
loop that loops through the sensor data repository (where records on<br>
each sensor are kept). That's where ipmi-fru finds the device IDs (e.g.<br>
ID 2) to look through. In the FRU SDR entry, there is another field for<br>
an fru_entity_id and fru_entity_instance (see<br>
freeipmi/templates/ipmi-sdr-record-format-templates.h). That entity ID<br>
and instance could be mapped to the entity-id/instance for the sensor<br>
SDR records (in combination w/ checking the sensor-type and a few other<br>
fields). This will probably work on most motherboards.<br>
<br>
However, this later part is quite complicated. You'd be<br>
scanning/parsing the SDR manually to find these little bits b/c it isn't<br>
normally available in libipmimonitoring.<br>
<br>
</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This is such a unique case, I doubt it'd be something that would "fit"<br>
along with any of the current freeipmi libraries. I can help you write<br>
something for NUT that is specific for your needs though. It can scan<br>
for FRU entries, then perhaps scan for sensor entries, and give you back<br>
record IDs?? Which can subsequently be pumped into libipmimonitoring<br>
for the specific sensors??<br></blockquote><div><br>I understand ;-)<br>do you think it involves duplicating a large chunk of the libs?<br><br>I'm trying to weight the pros and cons, and still consider a simple default (that works enough) with override params for nut-ipmipsu.<br>
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.<br><br>your help is still welcome, obviously. so thanks for your offer ;-)<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
> - the things I'm using to parse FRU (like ipmi_fru_parse_ctx_create)<br>
> and other things (lie ipmi_ctx_find_inband) are not available in<br>
> 0.7.17 (the base I'm working on, Ubuntu up to 11.04).<br>
> I've dug quickly the ChangeLog, but was not able to identify clearly<br>
> when these functions were added.<br>
> What is the minimal FreeIPMI required?<br>
<br>
</div>Most of these were added in FreeIPMI 0.8.1. Many of the core functions<br>
were initially only in tools and in FreeIPMI 0.8.1 they were<br>
"library-ized". There could be an odd-ball function here or there that<br>
were added in FreeIPMI 1.0.1, but I think you'd be safe with 0.8.1.<br></blockquote><div> <br>thanks for these hints.<br>I'll do some compilation testing to validate the final code.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
><br>
> ><br>
> > Hopefully that's enough to get you going. LMK if<br>
> you need<br>
> > some help<br>
> > deciphering the code more.<br>
> ><br>
> > this should not be needed, but thanks for your kind<br>
> proposition.<br>
> ><br>
> > but you should probably publish this code in examples/, with<br>
> a name<br>
> > like "simple-ipmi-fru.c" or alike, and highlight this code<br>
> sample a<br>
> > bit.<br>
><br>
><br>
> That's the plan eventually :P<br>
><br>
> so I've a minor patch for you (attached) ;)<br>
> it fixes indentation (replace tabs by spaces), and a typo on<br>
> 'frequenc*e*y'.<br>
> it may also be interesting to give the example compilation line in the<br>
> file header...<br>
<br>
</div>Somehow the patch came to me as 0 byte in length. Could you try again?<br></blockquote></div><br>strange!<br>I've checked my sent mail and it was 18 Kb.<br>anyway, it's attached again.<br><br>btw, have you been able to read my "improvement ideas" mail?<br>
<br>cheers,<br>Arno<br clear="all"><br>