[Freeipmi-devel] RE: ipmi-dcmi testing results

[Al Chu]

Hey Holger,

> Some more testing with the 0.8.2beta3 shows, that after deactivating
> the power limit, the --get-power-limit is choking on the completion
> code 0x80 (Power Limit not active), also a --set-power-limit
> --power-limit-requested=350 is reading the current setting before
> modifying the settings and also fails when the power limit is
> disabled.  The typical use case is more like configure some/all
> settings, and then activate the power limit. 

My copy of the spec says that the completion code is "No set power
limit" (and don't see a change in the errata), which I interpret to mean
that set power limit isn't supported?? Skimming through the dcmitool
code, it seems they do the same thing as me.  They call the 'get' first
then 'set' later.  I guess I don't quite understand how you/Fujitsu are
reading the spec differently than I am.

> Decoding of the 'out of range' completion codes would be helpful for 
> end users (unfortunately there is currently no way to get the actual 
> limits from the BMC other than with trial and error). 

I can definitely put code into to deal with this.

> The attached small patch activates correct packet decoding with
> --debug for DCMI commands, and corrects the --set-power-limit command
> template which had only a 3byte correction time instead of 32bits.

Thanks for the fixes, applied them all.

> P.S. Regarding OEM exception action we currently do support
> 'continue' (0x02) and 'shutdown' (0x03) in addition to the 'hard power
> off'. So it would be helpful to have the manufacturer_id and
> product_id around in a later version. What are the chances to get this
> added to the ipmi_ctx structure for general availability in all of the
> tools?

It's already in ipmi-sensors, ipmi-sel, and ipmi-fru (did some rework
recently that I went ahead and backported into 0.8.2, I'll release a
beta with this).  It'd be easy enough to copy into ipmi-dcmi.  The
problem is, I only get the manufactuer id and product id when
--interpret-oem-data is specified.  

Thinking about it a bit, perhaps I'll add --interpret-oem-data to
ipmi-dcmi so that the user will have to specify that if they want to
have OEM mapped output for --get-power-limit.

But for --set-power-limit, we'll create new inputs like
'fujitsu-shutdown'.  If those are selected, we grab the manufacturer
id/product id to make sure the input is legal for the remote
motherboard??

Sound like a plan?  I'm open to other ideas of course ...

Al

-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory