Hey Al,<br><br><div class="gmail_quote">2011/7/21 Albert Chu <span dir="ltr"><<a href="mailto:chu11@llnl.gov">chu11@llnl.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey Arnaud,<br>
<div><div></div><div class="h5"><br>
On Wed, 2011-07-20 at 13:29 -0700, Arnaud Quette wrote:<br>
> Hey Al,<br>
><br>
> 2011/7/19 Albert Chu <<a href="mailto:chu11@llnl.gov">chu11@llnl.gov</a>><br>
> > (...)<br>
> > I assuming you mean libipmidetect? libipmidetect is<br>
> primarily<br>
> > used for<br>
> > detecting if ipmi over LAN exists, not for<br>
> 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<br>
> detection<br>
> > over the network.<br>
> > but for now, I've released a preliminary version of<br>
> 'nut-ipmipsu',<br>
> > which supports only FRU info retrieval.<br>
> > It is available in NUT trunk, includes an m4 macro (ready<br>
> for<br>
> > pkgconfig, but currently using AC_CHECK_HEADERS/FUNCS), and<br>
> an<br>
> > abstracted IPMI implementation (only provided by FreeIPMI).<br>
> ><br>
> > I still have to had the sensor's info, and have 2 questions<br>
> for you:<br>
> > - is there a way to automatically determine which sensor is<br>
> attached<br>
> > to an FRU?<br>
> > Ie, I've found that the first PSU is ID 2. But how do I know<br>
> that<br>
> > sensor X is the one attached to this board?<br>
><br>
><br>
><br>
> Whew. It's not going to be easy. The current FRU format does<br>
> not<br>
> support information to point you to the specific sensor<br>
> record.<br>
><br>
> that's sad, since to an IPMI newbie like me, such a reference seems<br>
> obviously required and mandatory.<br>
> I was pretty sure that I was missing something around the sensor owner<br>
> ID, order of appearance (ie the 1rst PSU FRU with the first PSU<br>
> sensor) or alike.<br>
><br>
> If you tried to match power supply names (e.g. "PS 1"), that<br>
> would<br>
> probably work for many motherboards. However, there is no<br>
> guarantee<br>
> that a motherboard would ensure the FRU power supply name<br>
> matches the<br>
> sensor one. In fact, I looked at one motherboard I have here,<br>
> and they<br>
> don't match.<br>
><br>
> I *think* there is another way, but it gets complicated. You<br>
> start to<br>
> dig into a lot of IPMI specifics and nuances (which most of<br>
> the FreeIPMI<br>
> libraries naturally try to hide).<br>
><br>
> If you take a look at the original ipmi-fru code,<br>
> run_cmd_args() has a<br>
> loop that loops through the sensor data repository (where<br>
> records on<br>
> each sensor are kept). That's where ipmi-fru finds the device<br>
> IDs (e.g.<br>
> ID 2) to look through. In the FRU SDR entry, there is another<br>
> field for<br>
> an fru_entity_id and fru_entity_instance (see<br>
> freeipmi/templates/ipmi-sdr-record-format-templates.h). That<br>
> entity ID<br>
> and instance could be mapped to the entity-id/instance for the<br>
> sensor<br>
> SDR records (in combination w/ checking the sensor-type and a<br>
> 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<br>
> b/c it isn't<br>
> normally available in libipmimonitoring.<br>
><br>
> This is such a unique case, I doubt it'd be something that<br>
> would "fit"<br>
> along with any of the current freeipmi libraries. I can help<br>
> you write<br>
> something for NUT that is specific for your needs though. It<br>
> can scan<br>
> for FRU entries, then perhaps scan for sensor entries, and<br>
> give you back<br>
> record IDs?? Which can subsequently be pumped into<br>
> libipmimonitoring<br>
> for the specific sensors??<br>
><br>
> I understand ;-)<br>
> do you think it involves duplicating a large chunk of the libs?<br>
<br>
</div></div>I doubt it would be a tremendous amount of code.<br></blockquote><div><br>glad to hear this confirmation :)<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 class="im">
> I'm trying to weight the pros and cons, and still consider a simple<br>
> default (that works enough) with override params for nut-ipmipsu.<br>
> ie, default to the order of appearance (I still have to "validate"<br>
> this), and provide psuID and sensorID params to force targets if this<br>
> doesn't work.<br>
><br>
> your help is still welcome, obviously. so thanks for your offer ;-)<br>
<br>
</div>No prob.<br></blockquote><div><br>as per your above comment, I'm interested in a code sample if you have a bit of time...<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><div class="h5">
> > - the things I'm using to parse FRU (like<br>
> ipmi_fru_parse_ctx_create)<br>
> > and other things (lie ipmi_ctx_find_inband) are not<br>
> 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<br>
> clearly<br>
> > when these functions were added.<br>
> > What is the minimal FreeIPMI required?<br>
><br>
><br>
> Most of these were added in FreeIPMI 0.8.1. Many of the core<br>
> 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<br>
> there that<br>
> were added in FreeIPMI 1.0.1, but I think you'd be safe with<br>
> 0.8.1.<br>
><br>
> thanks for these hints.<br>
> I'll do some compilation testing to validate the final code.<br>
><br>
><br>
> ><br>
> > ><br>
> > > Hopefully that's enough to get you going.<br>
> LMK if<br>
> > you need<br>
> > > some help<br>
> > > deciphering the code more.<br>
> > ><br>
> > > this should not be needed, but thanks for your<br>
> kind<br>
> > proposition.<br>
> > ><br>
> > > but you should probably publish this code in<br>
> examples/, with<br>
> > a name<br>
> > > like "simple-ipmi-fru.c" or alike, and highlight<br>
> 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<br>
> line in the<br>
> > file header...<br>
><br>
><br>
> Somehow the patch came to me as 0 byte in length. Could you<br>
> try again?<br>
><br>
> strange!<br>
> I've checked my sent mail and it was 18 Kb.<br>
> anyway, it's attached again.<br>
<br>
</div></div>I got it this time. Yeah, the tabbing issue was me hacking together an<br>
example too quickly. But the typo I can put into the mainline code.<br></blockquote><div><br>ok, thanks.<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 class="im">
> btw, have you been able to read my "improvement ideas" mail?<br>
<br>
</div>Yeah, I read it awhile back. Like many projects, there is a bit of a<br>
momentum thing going on. I sort of logged it to memory as something for<br>
the future to consider.<br></blockquote><div><br>perfect, I just wanted to be sure that you at least had a ticket in mind ;-)<br><br>cheers,<br>Arnaud <br></div></div><br>