Hi Chris, On Sun, 2010-08-29 at 20:12 -0700, Christopher Maestas wrote: > I guess another question I would ask, is when will ipmi 1.5 be > deprecated and the default be 2.0? I was just curious when defaults > should move away.
The short answer is not anytime soon. The IPMI 2.0 spec states all IPMI 2.0 systems shall support IPMI 1.5. Given a number of older systems support IPMI 1.5 but not IPMI 2.0, it makes sense to keep the default IPMI 1.5. I believe ipmitool and ipmiutil have this policy as well. Al > > This server is a proliant dl385g5 server (amd barcelona quad core). I > have also tested on a bl460g6 (proliant blade Intel 6 core). > > On Wed, Aug 25, 2010 at 11:07 AM, Albert Chu <ch...@llnl.gov> wrote: > Hey Chris, > > (Moving this to freeipmi-devel, since this is more of a devel > discussion) > > > I'm sorry I should have tagged that first case of using > ipmipower as > > an error. > > > Does HP believe this to be a bug in their firmware? Many of > the tests > in the freeipmi-testing document use IPMI 1.5 specifically > (instead of > IPMI 2.0), so we'll want to get this bug fixed so you can pass > those > tests too. > > Also, as an FYI, what motherboard are you testing on? So that > I can > document this stuff. > > Al > > > On Tue, 2010-08-24 at 19:38 -0700, Christopher Maestas wrote: > > Al, > > > > > > I'm sorry I should have tagged that first case of using > ipmipower as > > an error. Once I added "-D LAN_2_0 " things worked great. > I think I > > also figured out the freeipmi.conf parameter (driver-type > LAN_2_0) to > > change to make it work by default and still talk to lo100 > and iLO > > devices without any issue at first glance > > > > > > Things are running fine now. I will continue to do some > more testing > > tomorrow with SOL, sensor gatherings. In addition I will > try and > > report back on conman/powerman using their ipmi drivers work > against > > the iLO server as well. > > > > > > Finally I will try and take a look at some tests specified > here: > > > > > > > http://**www.**gnu.org/software/freeipmi/freeipmi-testing.txt > > > > > > and report back. > > > > -cdm > > > > > > On Tue, Aug 24, 2010 at 5:11 PM, Albert Chu <ch...@llnl.gov> > wrote: > > Hi Chris, > > > > > For freeipmi (ipmipower) I found the following > combination > > worked: > > > --- > > > # ipmipower -h cut0iogw1-ilo -s > > > cut0iogw1-ilo: authentication type unavailable for > attempted > > privilege level > > > > > > This isn't good. It suggests that the HP firmware > might be > > returning > > bad/poor information in the Get Authentication > Capabilities > > phase of > > IPMI. Does ipmipower work if you also specify the > authcap > > workaround? > > (-W authcap). > > > > If it does work, then there is a bug. Perhaps you > can send me > > a --debug > > output and we can take a look to figure out what the > bug is. > > > > Al > > > > > > On Tue, 2010-08-24 at 15:29 -0700, Christopher > Maestas wrote: > > > Hello, > > > > > > With the recent update of the 2.00 iLO2 firmware, > we can now > > support: > > > > > > > > > - "IPMI over LAN" functionality. The IPMI 2.0 > RMCP+ (or > > Linux ipmitool > > > "lanplus") protocol is supported with this > release. > > > - IPMI Serial Over LAN (SOL) > > > - Data Center Manageability Interface (DCMI) > v1.0 > > specification > > > - Enhanced the "in band" Intelligent Platform > Management > > Interface (IPMI) > > > to comply with the IPMI specification version > 2.0 > > > > > > I've been able to use ipmitool to test this > successfully > > (power, SOL and > > > sensor gathering). Here's what I do with > ipmitool: > > > --- > > > # rpm -q ipmitool > > > ipmitool-1.8.11-1 > > > # ipmitool -I lanplus -H cut0iogw1-ilo -U USER -P > PASS power > > status > > > Chassis Power is off > > > # ipmitool -I lanplus -H cut0iogw1-ilo -U USER -P > PASS power > > on > > > Chassis Power Control: Up/On > > > # ipmitool -I lanplus -H cut0iogw1-ilo -U USER -P > PASS power > > status > > > Chassis Power is on > > > --- > > > > > > For freeipmi (ipmipower) I found the following > combination > > worked: > > > --- > > > # ipmipower -h cut0iogw1-ilo -s > > > cut0iogw1-ilo: authentication type unavailable for > attempted > > privilege level > > > # ipmipower -h cut0iogw1-ilo -D LAN_2_0 -s > > > cut0iogw1-ilo: on > > > # ipmipower -h cut0iogw1-ilo -D LAN_2_0 -f > > > cut0iogw1-ilo: ok > > > # ipmipower -h cut0iogw1-ilo -D LAN_2_0 -s > > > cut0iogw1-ilo: off > > > # ipmipower -h cut0iogw1-ilo -D LAN_2_0 -n > > > cut0iogw1-ilo: ok > > > # ipmipower -h cut0iogw1-ilo -D LAN_2_0 -s > > > cut0iogw1-ilo: on > > > --- > > > > > > I set the following in /etc/freeipmi.conf: > > > --- > > > driver-type LAN_2_0 > > > --- > > > > > > and it seems to work ok for the lo100 and ilo2 > servers just > > fine. > > > --- > > > # ipmipower -h cut0iogw1-ilo -s > > > cut0iogw1-ilo: on > > > # ipmipower -h cut0admin1-lo -s > > > cut0admin1-lo: on > > > --- > > > > > > I figure there may be other functional tests for > ipmi > > compliance I can run > > > now that the initial flags have been worked around > for > > freeipmi's ipmipower > > > command. Then I figure on changing > powerman/conman to use > > ipmi drivers for > > > ilo devices and see how that works. > > > > > > Thanks, > > > -cdm > > > > > _______________________________________________ > > > Freeipmi-users mailing list > > > freeipmi-us...@gnu.org > > > > http://***lists.gnu.org/mailman/listinfo/freeipmi-users > > > > > -- > > Albert Chu > > ch...@llnl.gov > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory > > > > > > > > -- > > Albert Chu > ch...@llnl.gov > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > > > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel