freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Al Chu
Subject: Re: [Freeipmi-devel] RE: ipmi-dcmi testing results
Date: Tue, 15 Dec 2009 17:08:46 -0800

Hey Holger,

I've put a new beta up:

http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.2.beta4.tar.gz

Al

On Tue, 2009-12-15 at 15:27 -0800, Al Chu wrote:
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]