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 [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
