Re: [Freeipmi-users] fish crashes with Segmentation fault at startup
I'm assuming from the Troubleshooting section of the documentationthat 'ipckey' doesn't contain any data, it's just the inode number that gets used. It's just a place holder for ftok(). As long as its there, things should be fine. Just to be sure, when I built I used GUILE=/usr/local/bin/guile GUILE_CONFIG=/usr/local/bin/guile-config GUILE_TOOLS=/usr/local/bin/guile-tools in the 'configure' command-line. I've never had to build against a non-default GUILE, so I'm not 100% sure about whether the above will work. But now that you mention it, it's possible your build is confused b/c of its compiling against the guile in /usr/lib. You may want to try setting the LDFLAGS=-L /usr/local/lib and CPPFLAGS=/usr/local/include. This should tell the compiler to search those paths first. Just thinking as I type, fish should use the version under what's specified by --prefix --exec-prefix, /usr/local by default, and not what's in $PATH. My understanding is that --prefix and --exec-prefix are only for installation location and will not affect library linking. There isn't a connection with the shell used is there? Both the target and the chroot'ed build-host run ash whereas the normal build-host environment is bash. There shouldn't be. Good luck, Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: [EMAIL PROTECTED] Date: Friday, November 4, 2005 9:57 am Subject: Re: [Freeipmi-users] fish crashes with Segmentation fault at startup Hi, Albert. Thanks for the quick response ... see in-line replies below Just to make sure, this is the Freeipmi 0.1.3 version? Yes, I just downloaded version 0.1.3 from the freeipmi.gnu.org site the other day. 1) Since this is a chrooted environment, is it possible you don't haveall the same file system mounts in your chrooted environment as you do in your normal environment? Off the top of my head, the libfreeipmi library stores/uses a few things in /var/lib. So if there isn't a /var,some things may get messed up. Fish also reads from some files in a few other directories. This is just a guess of course. Yes, I spotted that. I did a 'make -n install ~/install.log' and then grep'ed for 'mkinstalldirs' to see where things were being stored and then manuallycreated the bits that were missed when I copied the contents of '/usr/local' over to the image file. I'll double-check that I've not missed somethinghere. I'm assuming from the Troubleshooting section of the documentationthat 'ipckey' doesn't contain any data, it's just the inode number that gets used. Just to be sure, when I built I used GUILE=/usr/local/bin/guile GUILE_CONFIG=/usr/local/bin/guile-config GUILE_TOOLS=/usr/local/bin/guile-tools in the 'configure' command- line. This should mean that the build uses only what I built and installed under /usr/local, right? Just thinking as I type, fish should use the version under what's specifiedby --prefix --exec-prefix, /usr/local by default, and not what's in $PATH. The standard RedHat 9-1 distro. of guile/readline and what I built are slightly different versions. 2) Is the 2.4.31 IPMI kernel driver turned on? FreeIPMI doesn't requireit, and wouldn't think that the kernel driver would interfere with libfreeipmi, but who knows. Hmmm, I can't remember if the kernel driver is enabled. Again, I'll double-check the .config file. However, since I don't get the poblem with the build-host unless I 'chroot' to the mounted image file (i.e. the RedHat 2.4.20- 8 kernel without IPMI is still running, it's just the file-system that's changed)I don't think that's the cause either. There isn't a connection with the shell used is there? Both the target and the chroot'ed build-host run ash whereas the normal build-host environmentis bash. I forgot to mention, the 2.4.31 kernel was built with patches from i2c-2.9.2 and lm_sensors-2.9.2 though the kernel modules aren't (yet) loaded. Justa thought but since I get the same (apparent) problem with two differentkernels it's maybe not relevant. Looks like I need to rebuild with debug on and try to work with the core-dump in gdb. Thanks, Rob ___ Unlimited Tiscali Broadband from 14.99! http://www.tiscali.co.uk/products/broadband/ ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] fish crashes with Segmentation fault at startup
Hi Rob, Thanks for figuring this out and finding the bug. I have submitted a bug for Balamarugan to fix this. I think it is a bug for fish to assume the user has a home directory. I've asked that if a home directory isn't found, then fish should instead fall back to some default location (/var or /tmp or something). Regarding bmc-info, does bmc-info actually return and not output anything? Or does the the command hang and not do anything? The later (usually) indicates that libfreeipmi is having trouble finding the default KCS port to read/write data to the BMC. Since this is an embedded system of some sort I would assume the KCS port might not be the default (and the 0.1.3 release has some difficulty finding the non-default ports). I believe you can set the alternate default port in /etc/fish.scm for FreeIPMI 0.1.3. Hopefully your system doesn't have register spacing issues, b/c that might require you to use a newer version we have checked into CVS. I think you can determine your systems default port through: dmidecode | grep -i ipmi --context=10 The context of 10 should be enough to show you all the info you need. LMK how it goes, Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: [EMAIL PROTECTED] Date: Monday, November 7, 2005 11:09 am Subject: Re: [Freeipmi-users] fish crashes with Segmentation fault at startup Hi, Albert. Problem solved ! Well, one of them anyway ... The trouble was that my chroot'ed environment and the target system werejust a bit too minimal. When fish starts up it checks to see what the home directory of the current user is (in fi-utils.c, get_home_directory). Because I had no /etc/nsswitch.conf (set to use files for all) and no /lib/libnss_files.so.2,get_home_directory returned NULL which the strlen in get_config_directory didn't like at all ! I now get a 'fish#' prompt on my target system. Having copied /usr/local/etc/fish/fish/scm over the blank file, /root/.fish/fish.scm(I'm running as root) I dont get any output from bmc-info. Is there anything else I should do to configure freeipmi ? Thanks, Rob ___ Unlimited Tiscali Broadband from 14.99! http://www.tiscali.co.uk/products/broadband/ ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmipower over IP - IBM eServer 325
Hi Gerald,
I'm looking through the tcpdump to try and figure things out. In the
meantime, if you happened to compile from source, do you think you could
try to run:
ipmipower -h hostname -u username -p password --on --debug --ipmidump
That would give me an easier dump to work with. You'd have to compile
with ./configure --enable-debug to get the later two options to build.
Thanks,
Al
--
Albert Chu
[EMAIL PROTECTED]
Lawrence Livermore National Laboratory
- Original Message -
From: Gerald Nowitzky [EMAIL PROTECTED]
Date: Monday, November 7, 2005 2:03 pm
Subject: [Freeipmi-users] ipmipower over IP - IBM eServer 325
Hi!
I am using freeipmi 0.1.3, trying to remote-control a IBM eServer 325
Opteron System. I get a response from the system using ipmiping:
ipmiping -v 192.168.0.58
ipmiping 192.168.0.58 (192.168.0.58)
response received from 192.168.0.58: rq_seq=0, auth: none=set
md2=clearmd5=set passwd=set oem=clear permsg=set user=set
however:
ipmipower -h 192.168.0.58 -u USERID -p bongo --on
192.168.0.58: timed out
I had tcpdump to catch the packets between my pc (192.168.0.23) and
theIBM-eServer-IPMI (192.168.0.58):
20:49:09.036201 IP 192.168.0.23.32943 192.168.0.58.623: UDP,
length: 23
0x: 4500 0033 4000 4011 b918 c0a8 0017
[EMAIL PROTECTED]@...0x0010: c0a8 003a 80af 026f 001f c909 0600 ff07
...:...o 0x0020:
0009 2018 c881 0438 ...8 0x0030:
0e0332 ..2
20:49:09.079241 IP 192.168.0.58.623 192.168.0.23.32943: UDP,
length: 30
0x: 4500 003a 0028 1e11 1aea c0a8 003a
E..:.(.:0x0010: c0a8 0017 026f 80af 0026 f7c5 0600 ff07
.o. 0x0020:
0010 811c 6320 0438 c..8 0x0030:
0001151d ..
20:49:09.080474 IP 192.168.0.23.32943 192.168.0.58.623: UDP,
length: 38
0x: 4500 0042 0001 4000 4011 b908 c0a8 0017
[EMAIL PROTECTED]@...0x0010: c0a8 003a 80af 026f 002e 168d 0600 ff07
...:...o 0x0020:
0018 2018 c881 0839 ...9 0x0030:
04555345 5249 .USERI
20:49:09.133397 IP 192.168.0.58.623 192.168.0.23.32943: UDP,
length: 42
0x: 4500 0046 0029 1e11 1add c0a8 003a
E..F.).:0x0010: c0a8 0017 026f 80af 0032 bad7 0600 ff07
.o...2.. 0x0020:
001c 811c 6320 0839 c..9 0x0030:
00045863 2191 ..Xc!.
20:49:09.134199 IP 192.168.0.23.32943 192.168.0.58.623: UDP,
length: 59
0x: 4500 0057 0002 4000 4011 b8f2 c0a8 0017
[EMAIL PROTECTED]@...0x0010: c0a8 003a 80af 026f 0043 442f 0600 ff07
...:...o.CD/ 0x0020:
0400 0004 5863 2162 6f6e 676f ..Xc!bongo.. 0x0030:
..
20:49:09.535212 IP 192.168.0.23.32943 192.168.0.58.623: UDP,
length: 59
0x: 4500 0057 0003 4000 4011 b8f1 c0a8 0017
[EMAIL PROTECTED]@...0x0010: c0a8 003a 80af 026f 0043 442f 0600 ff07
...:...o.CD/ 0x0020:
0400 0004 5863 2162 6f6e 676f ..Xc!bongo.. 0x0030:
..
20:49:09.936126 IP 192.168.0.23.32943 192.168.0.58.623: UDP,
length: 59
0x: 4500 0057 0004 4000 4011 b8f0 c0a8 0017
[EMAIL PROTECTED]@...0x0010: c0a8 003a 80af 026f 0043 442f 0600 ff07
...:...o.CD/ 0x0020:
0400 0004 5863 2162 6f6e 676f ..Xc!bongo.. 0x0030:
..
...
Any Idea what is going wrong?
Thanks a lot!
(Gerald)
___
Freeipmi-users mailing list
Freeipmi-users@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-users
___
Freeipmi-users mailing list
Freeipmi-users@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] IBM eServer 325 workaround
Hi Gerald, Carson Gaspar, a fellow I found through the ipmitool mailing list, was able to determine what the problem was with the IBM eServer325. I was able to test a patched version of 'ipmipower' and it worked. Short story. there is a flag called per msg authentication in the beginning of IPMI protocol. The flag, to some degree, directs how later IPMI packets should be generated. The IBM eServer sets the flag but later in the protocol assumes it isn't set. I'm not entirely sure of the best way to deal with this right now. This is the first vendor workaround that I'll have to do the opposite of what the protocol tells me to do. I'm thinking of a --ibmeserver325 option. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] OK, i give...
Hi Karl, Whoops, I didn't answer the second half of your e-mail. Commit Section User2 Key Username Value Operator FAILED Commit Section User3 Key Username Value Administrator FAILED Commit Section User4 Key Username Value CallBack FAILED Commit Section Misc Key Power_Restore_Policy Value Off_State_Ac_Apply FAILED Some BMCs do not offer the ability to configure every field. It may be that your BMC does not allow you to change the usernames, but apparently you can change fields related to the username. Likewise with the Power_Restore_Policy. What system are you doing this on? Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Karl Hanzel [EMAIL PROTECTED] Date: Thursday, December 1, 2005 3:30 pm Subject: [Freeipmi-users] OK, i give... I'm interested in using 'ipmipower' to control the up/down'ness of a host. Of course there must be some form of authentication/authorization involved, but it's not immediately obvious how to set this up. How does one set a user/password witm bmc-config? Or am i barking up the wrong tree? If i simply do a bmc-config --checkout --filename=/tmp/tmp followed immediately (no editing of /tmp/tmp) by a bmc-config --commit --filename=/tmp/tmp i get the following output: Commit Section User2 Key Username Value Operator FAILED Commit Section User3 Key Username Value Administrator FAILED Commit Section User4 Key Username Value CallBack FAILED Commit Section Misc Key Power_Restore_Policy Value Off_State_Ac_Apply FAILED which doesn't seem very promising. Thanks for any tips. I feel like i'm pioneering here. Karl * Karl Hanzel UCAR/COMET Systems Administrator Boulder, Colorado (303)497-8479 [EMAIL PROTECTED] ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] OK, i give...
I've never worked on the Tyan boards before, so I'm not sure about them. A.B. or Balamarugan have worked on them before. So I'll have to wait for what they say :-) Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Karl Hanzel [EMAIL PROTECTED] Date: Thursday, December 1, 2005 4:03 pm Subject: Re: [Freeipmi-users] OK, i give... that your BMC does not allow you to change the usernames, but apparently you can change fields related to the username. Likewise with the Power_Restore_Policy. What system are you doing this on? It's a TYAN 2881 dual Operteron board with an SMDC daughter card. *- ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] IBM eServer 325 workaround
Hey AB, I ended up implementing a --force-permsg-auth option for this isue. The problem with implementing what you suggest is what if IBM (I've sent e-mails to some engineering folks there) fixes the problem in a later firmware release? Or perhaps we don't know what range of products from IBM have this problem. It may only be some of them. Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Tuesday, December 13, 2005 5:05 pm Subject: Re: [Freeipmi-users] IBM eServer 325 workaround ,[ Albert Chu [EMAIL PROTECTED] ] | Hi Gerald, | | Carson Gaspar, a fellow I found through the ipmitool mailing list, | was able to determine what the problem was with the IBM eServer325. | I was able to test a patched version of 'ipmipower' and it worked. | | Short story. there is a flag called per msg authentication in the | beginning of IPMI protocol. The flag, to some degree, directs how | later IPMI packets should be generated. The IBM eServer sets the | flag but later in the protocol assumes it isn't set. | | I'm not entirely sure of the best way to deal with this right now. | This is the first vendor workaround that I'll have to do the | opposite of what the protocol tells me to do. I'm thinking of a | --ibmeserver325 option. ` Instead of --ibmeserver325 option, you should use the manf-id/prod-id from get_device_info command and automatically handle it from inside the libfreeipmi. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi_open_inband no such device on Ibm e325
Hey Rene,
I remember that thread. The IBM lancfg utility should be fine. What we
found was that there was a bug in the IBM IPMI firmware. So I had to
write a workaround in 'ipmipower' to work around the problem (the
--force-permsg-auth flag) [1]. I don't believe the problem should exist
in the other FreeIPMI over-LAN tools. Please let us know if there are
problems though.
Al
[1] - That does remind me though, I need to re-harass IBM about this bug :-)
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Rene Salmon [EMAIL PROTECTED]
Date: Friday, March 24, 2006 11:16 am
Subject: Re: [Freeipmi-users] ipmi_open_inband no such device on Ibm e325
Hi,
For the time being I would like to manage the machine with out-band
IPMI. I just updated the firmware and need I need to set the IP
and
password for the BMC. I can use the IBM IPMI config utility
(lancfg) to
do this but I found this post that hints to a problem if I use the
lancfg tool.
http://lists.gnu.org/archive/html/freeipmi-users/2005-11/msg00017.html
Should I just use lancfg to set the ip/passwd or is there a better
way
more freeimpi friendly?
Thanks
Rene
Albert Chu wrote:
Hey Rene,
Thanks. That verifies atleast why it's failing.
/* At this point we only support SYSTEM_IO, i.e. inb/outb style IO.
If we cant find the bass address, we better exit. -- Anand
Babu */
if (dev-io.inband.locate_info.addr_space_id !=
IPMI_ADDRESS_SPACE_ID_SYSTEM_IO)
{
errno = ENODEV;
return (-1);
}
The IBM's use memory mapped io. This is the first machine (that
I've seen) with memory mapped rather than port based i/o for in-
band IPMI.
A.B., Bala I'll leave this to you to follow up on. Needless to say,
this needs to be fixed. I think logically it shouldn't be too
hard to
add? Just need to map some INB/OUTB calls into read/writes? I
could give it a shot, but I lack a machine to test on.
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Rene Salmon [EMAIL PROTECTED]
Date: Friday, March 24, 2006 10:18 am
Subject: Re: [Freeipmi-users] ipmi_open_inband no such device on
Ibm e325
Hi,
Thanks for the help. Here is the output of ipmi-locate.
Probing KCS device using SMBIOS... done
IPMI Version: 1.5
IPMI locate driver: SMBIOS
IPMI locate driver: 0
IPMI interface: KCS
BMC I2C device: (null)
BMC memory base address: CA2
Register space: 0
Probing SMIC device using SMBIOS... FAILED
Probing BT device using SMBIOS... FAILED
Probing SSIF device using SMBIOS... FAILED
Probing KCS device using ACPI... FAILED
Probing SMIC device using ACPI... FAILED
Probing BT device using ACPI... FAILED
Probing SSIF device using ACPI... FAILED
Probing KCS device using PCI... FAILED
Probing SMIC device using PCI... FAILED
Probing BT device using PCI... FAILED
Probing SSIF device using PCI... FAILED
KCS device default values:
IPMI Version: 1.5
IPMI locate driver: DEFAULT
IPMI locate driver: 0
IPMI interface: KCS
BMC I2C device: (null)
BMC I/O base address: CA2
Register space: 1
SMIC device default values:
IPMI Version: 1.5
IPMI locate driver: DEFAULT
IPMI locate driver: 0
IPMI interface: SMIC
BMC I2C device: (null)
BMC I/O base address: CA9
Register space: 1
BT device default values:
SSIF device default values:
IPMI Version: 1.5
IPMI locate driver: DEFAULT
IPMI locate driver: 0
IPMI interface: SSIF
BMC I2C device: /dev/i2c-0
BMC SMBUS slave address: 20
Register space: 1
Albert Chu wrote:
Hi Rene,
Could you run the ipmi-locate tool so we can see what exactly
is
on that
machine?
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Rene Salmon [EMAIL PROTECTED]
Date: Friday, March 24, 2006 9:54 am
Subject: [Freeipmi-users] ipmi_open_inband no such device on
Ibm
e325
Hi list,
I am very new to IPMI and I am hoping to get some help here.
I have an IBM e325 server on which I am trying to run freeimpi
and
I am
getting the following error when I try to run bmc-info:
src/freeipmi# bmc-info
ipmi_open_inband(): No such device
Here is what i did:
downloaded and installed these packages on a SuSe-9.3 e325.
freeipmi-0.2.0-1.x86_64.rpm
freeipmi-utils-0.2.0-1.x86_64.rpm
freeipmi-devel-0.2.0-1.x86_64.rpm
freeipmi-fish-0.2.0-1.x86_64.rpm
After updating the BMC firmware and the BIOS on the server I
set
up
the
following in BIOS settings.
* Advanced
Re: [Freeipmi-users] Cat ate fish during bmc-config
Great. A.B., Bala, any time frame on a fix? Perhaps we can push this in before a 0.2.2 release? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Frank Hempel [EMAIL PROTECTED] Date: Tuesday, June 13, 2006 8:31 am Subject: Re: [Freeipmi-users] Cat ate fish during bmc-config That's it man! With the change it worked. Thank you! cu, Frank. Albert Chu schrieb: Hi Frank, Hmmm, it's erroring out before the checkout of the parameter Lan_Privilege_Limit. And the string-capitalize indicates there was an error in the input. Hmmm. I suppose it's possible the privilege level limit is invalid and doesn't map to a value correctly, thus bmc-config errors out. I'll submit a bug for the other FreeIPMI developers that work on that part of the code. In the meantime, could you try tweaking the code to give it a shot? (or if you want, just holler and I'll build you a test rpm.) Modify fish/extensions/bc-common.scm and change (define privilege-limit-values '((callback. 1) (user. 2) SNIP (no_access . #xF))) to (define privilege-limit-values '((reserved. 0) (callback. 1) (user. 2) SNIP (no_access . #xF))) then reinstall of course. My current bet is the default config of your BMC is invalid, and thus confuses bmc-config. Thanks, Al ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] sparc64 compilation errors
Hi Corentin, I just noticed that in our code someone defined a different typedef for u32. So maybe there's a collision. Lemme redo their typedef and see if it gets around the problem. Al Hello This is the io.h requested. Apparently it's the u32 and u16 typedef who isn't used. Cordially LABBE C. Secondly in configure script, i saw this: Perhaps it's relevant for you checking asm/io.h usability... no checking asm/io.h presence... yes configure: WARNING: asm/io.h: present but cannot be compiled configure: WARNING: asm/io.h: check for missing prerequisite headers? configure: WARNING: asm/io.h: see the Autoconf documentation configure: WARNING: asm/io.h: section Present But Cannot Be Compiled configure: WARNING: asm/io.h: proceeding with the preprocessor's result configure: WARNING: asm/io.h: in the future, the compiler will take precedence configure: WARNING: ## - ## configure: WARNING: ## Report this to freeipmi-devel@gnu.org ## configure: WARNING: ## - ## checking for asm/io.h... yes Albert Chu a écrit : Hi Corentin, Don't know about the issue off the top of my head. From the error messages, below it seems like it's a minor typedef/header file porting issue. /usr/include/asm-sparc/io.h:16: error: syntax error before flip_dword /usr/include/asm-sparc/io.h:16: error: syntax error before l Could you send me this io.h file? Maybe I can figure it out from that. Al Hello I want to use freeipmi on a sun blade100 (sparc64 platform). But freeipmi won't compile. The distribution used is gentoo. I first tried with the gentoo stable version of freeipmi 0.2.3 It failed with: sys/io.h: No such file or directory I saw that this error is corriged, so i tried lastest version 0.3.1 but it also failed This is the error: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./../include -I./../../common/src -DIPMI_IPCKEY=\/usr/local/var/lib/freeipmi/ipckey\ -DIPMI_DEBUG_IPCKEY=\../../libfreeipmi/src/ipmi-semaphores.h\ -D_GNU_SOURCE -D_REENTRANT -Wall -g -O2 -MT libfreeipmi_la-ipmi-kcs-api.lo -MD -MP -MF .deps/libfreeipmi_la-ipmi-kcs-api.Tpo -c ipmi-kcs-api.c -fPIC -DPIC -o .libs/libfreeipmi_la-ipmi-kcs-api.o In file included from /usr/include/asm/io.h:4, from ipmi-inband.h:43, from ipmi-kcs-api.c:45: /usr/include/asm-sparc/io.h:16: error: syntax error before flip_dword /usr/include/asm-sparc/io.h:16: error: syntax error before l /usr/include/asm-sparc/io.h: In function `flip_dword': /usr/include/asm-sparc/io.h:18: error: `l' undeclared (first use in this function) /usr/include/asm-sparc/io.h:18: error: (Each undeclared identifier is reported only once /usr/include/asm-sparc/io.h:18: error: for each function it appears in.) /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:21: error: syntax error before flip_word /usr/include/asm-sparc/io.h:21: error: syntax error before w /usr/include/asm-sparc/io.h: In function `flip_word': /usr/include/asm-sparc/io.h:23: error: `w' undeclared (first use in this function) /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:32: error: syntax error before __raw_readb /usr/include/asm-sparc/io.h: In function `__raw_readb': /usr/include/asm-sparc/io.h:34: error: syntax error before u8 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:37: error: syntax error before __raw_readw /usr/include/asm-sparc/io.h: In function `__raw_readw': /usr/include/asm-sparc/io.h:39: error: syntax error before u16 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:42: error: syntax error before __raw_readl /usr/include/asm-sparc/io.h: In function `__raw_readl': /usr/include/asm-sparc/io.h:44: error: syntax error before u32 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:47: error: syntax error before b /usr/include/asm-sparc/io.h: In function `__raw_writeb': /usr/include/asm-sparc/io.h:49: error: syntax error before u8 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:52: error: syntax error before w /usr/include/asm-sparc/io.h: In function `__raw_writew': /usr/include/asm-sparc/io.h:54: error: syntax error before u16 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:57: error: syntax error before l /usr/include/asm-sparc/io.h: In function `__raw_writel': /usr/include/asm-sparc/io.h:59: error: syntax error before u32 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:62: error: syntax error before __readb /usr/include/asm-sparc/io.h: In function `__readb': /usr/include/asm-sparc/io.h:64: error: syntax error before u8 /usr/include/asm-sparc/io.h: At top level: /usr/include/asm-sparc/io.h:67: error: syntax error before __readw /usr/include/asm-sparc/io.h: In function `__readw': /usr/include/asm-sparc/io.h:69: error
[Freeipmi-users] bmc-autoconfig: drop for 0.5.0 release?
I'm thinking of dropping this from FreeIPMI: A) It doesn't seem to be maintained by the original authors. B) It apparenly only configures 3 fields of the BMC. No users, lan enabling, etc. I don't really see the use anymore. Any comments? Anyone out there using this? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.4.3 Released
Howdy everyone, Major addition is workarounds to support ASUS motherbaords. Various minor bug fixes besides that. http://ftp.zresearch.com/pub/freeipmi/0.4.3/ 0.4.3 - o Add ASUS P5M2 workarounds in ipmipower, ipmiconsole, and ipmimonitoring. o Fix bad input assert corner cases. o Fix non-default install bug. o Fix range check in bmc-config SOL config that was inconsistent with IPMI spec. o Fix ipmipower config file logic bug. o Fix ipmipower config output logic bug. o Fix potential pre-processor compile bug. o Fix manpage typos. o Fix error output messages in bmc-config. o Fix legacy config option issues. o Fix usage help in ipmiconsole. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] freeipmi 0.3.3 on a dell poweredge 2950
Hi Florian, It seems like there's a pthread's library issue on BSD. I really have to defer to Dmitry, our BSD expert who handles our BSD porting. I've CCed him. Al This is the message I finaly got during make build: ---snip-- gmake[4]: Leaving directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3/libfreeipmi/src' gmake -C ../../common/src/ libfreeipmiportability.la gmake[4]: Entering directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3/common/src' gmake[4]: `libfreeipmiportability.la' is up to date. gmake[4]: Leaving directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3/common/src' /bin/sh /usr/local/bin/libtool --mode=link --tag=CC cc -Wall -O2 -fno-strict-aliasing -pipe -L/usr/local/lib -o ipmi-fru ipmi-fru.o ipmi-fru-argp.o ipmi-fru-info-area.o ipmi-fru-multirecord-area.o ipmi-fru-util.o ../../common/src/libargpcommon.la ../../common/src/libtoolcommon.la ../../common/src/libsdr.la ../../common/src/libpstdout.la ../../common/src/libhostrange.la ../../common/src/libcbuf.la ../../common/src/libllnlcommon.la ../../ipmidetect/src/libipmidetect/libipmidetect.la ../../libfreeipmi/src/libfreeipmi.la ../../common/src/libfreeipmiportability.la -largp -lm mkdir .libs *** Warning: Linking the executable ipmi-fru against the loadable module *** libfreeipmi.so is not portable! cc -Wall -O2 -fno-strict-aliasing -pipe -o .libs/ipmi-fru ipmi-fru.o ipmi-fru-argp.o ipmi-fru-info-area.o ipmi-fru-multirecord-area.o ipmi-fru-util.o -L/usr/local/lib ../../common/src/.libs/libargpcommon.a ../../common/src/.libs/libtoolcommon.a ../../common/src/.libs/libsdr.a ../../common/src/.libs/libpstdout.a ../../common/src/.libs/libhostrange.a ../../common/src/.libs/libcbuf.a ../../common/src/.libs/libllnlcommon.a ../../ipmidetect/src/libipmidetect/.libs/libipmidetect.so ../../libfreeipmi/src/.libs/libfreeipmi.so /usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so -lintl ../../common/src/.libs/libfreeipmiportability.a -largp -lm -Wl,--rpath -Wl,/usr/local/lib ../../common/src/.libs/libpstdout.a(libpstdout_la-pstdout.o)(.text+0x1b85): In function `pstdout_launch': : undefined reference to `pthread_attr_init' ../../common/src/.libs/libpstdout.a(libpstdout_la-pstdout.o)(.text+0x1bac): In function `pstdout_launch': : undefined reference to `pthread_attr_setdetachstate' ../../common/src/.libs/libpstdout.a(libpstdout_la-pstdout.o)(.text+0x1c70): In function `pstdout_launch': : undefined reference to `pthread_create' ../../common/src/.libs/libpstdout.a(libpstdout_la-pstdout.o)(.text+0x1d94): In function `pstdout_launch': : undefined reference to `pthread_attr_destroy' gmake[3]: *** [ipmi-fru] Error 1 gmake[3]: Leaving directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3/ipmi-fru/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3/ipmi-fru' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/sysutils/freeipmi4/work/freeipmi-0.4.3' gmake: *** [all] Error 2 *** Error code 2 ---snap-- Anand Babu Periasamy schrieb: Hi Florian, Can you post the compilation errors? ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.4.4 Released
Howdy everyone, Just a few minor fixes in this one. 0.4.4 - o Alter userncame-capabilities workaround to authentication-capabilities workaronds to cover more situations. o Fix libipmiconsole new console port corner case. o Fix manpage typos. http://ftp.zresearch.com/pub/freeipmi/0.4.4/ Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] freeipmi on freebsd 4.x
I agree with Dmitry's earlier e-mail, something's a little strange. Everything on that board is unknown or 0. I know that IPMI works on atleast some motherboards in that line of motherboards from Supermicro. You have to purchase the additional IPMI daughter card though. If you've purchased one, maybe it's not seated properly?? I know they can fall out easily. We've sometimes seen them completely fall out of the slot when moving the machine around. Al Hi, Thanks for your help. On one of my system # dmidecode Handle 0x0027 DMI type 38, 18 bytes. IPMI Device Information Interface Type: Unknown Specification Version: 0.0 I2C Slave Address: 0x00 NV Storage Device Address: 0 Base Address: 0x (Memory-mapped) Register Spacing: Successive Byte Boundaries Interrupt Polarity: Active Low Interrupt Trigger Mode: Edge ie i2c slave address is 0x0 but ipmi-locate is not showing this 0x0 address su-2.04# ./ipmi-locate[This is from i just worked on freeipmi 0.5 beta] Probing KCS device using DMIDECODE... FAILED Probing SMIC device using DMIDECODE... FAILED Probing BT device using DMIDECODE... FAILED Probing SSIF device using DMIDECODE... FAILED Probing KCS device using SMBIOS... FAILED Probing SMIC device using SMBIOS... FAILED Probing BT device using SMBIOS... FAILED Probing SSIF device using SMBIOS... FAILED Probing KCS device using ACPI... FAILED Probing SMIC device using ACPI... FAILED Probing BT device using ACPI... FAILED Probing SSIF device using ACPI... FAILED Probing KCS device using PCI... FAILED Probing SMIC device using PCI... FAILED Probing BT device using PCI... FAILED Probing SSIF device using PCI... FAILED KCS device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: KCS BMC driver device: BMC I/O base address: CA2 Register spacing: 1 SMIC device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: SMIC BMC driver device: BMC I/O base address: CA9 Register spacing: 1 BT device default values: SSIF device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: SSIF BMC driver device: /dev/i2c-0 BMC SMBUS slave address: 42 Register spacing: 1 What does it mean? Is there something wrong with this box? hw.smbios.system.manufacturer: Supermicro hw.smbios.system.product_name: X6DH8 Whereas on Intel box ipmi-locate is showing slave address same as dmidecode is showing. If you need any 4.x testing, I can provide you the tool output. Thanks Sharad Chandra -- * Sharad Chandra [EMAIL PROTECTED] [21.11.2007 12:24]: Hi, A quick question, What is the latest freeipmi package that i can install on freebsd 4.x, I had freeipmi -0.2 beta version on one of my system but ipmi-locate doesn't show probing devices using dmidecode any where. The latest version of FreeIPMI, that I was able to run on 4.x was 0.2.3. You can get port tarball here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/freeipmi/freeipmi.tar.gz ?only_with_tag=RELEASE_6_2_0;tarball=1 Does something about IPMI show up when You run dmidecode utility (ports/sysutils/dmidecode)? Try dmidecode | grep -i -A10 ipmi as root. I tried to compile freeipmi-0.5 beta0 with its dependency taken from RELEASE_4_EOL branch, but at last i found, E-mail, forwarded by Al, says it all. To summarize: to run fresh FreeIPMI on FBSD 4.x one would need to workaround absence of stdint.h and of getpw*_r() functions at least. Unfortunately, I don't even have 4.x system at hand, so can't try. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.5.0-beta2 Released
Includes a few minor fixes + Dmitry's BSD compile bug patch. I'm hoping this is the last beta. ftp://ftp.zresearch.com/pub/freeipmi/0.5.0.beta/ Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.5.0 Beta3 Released
One manpage fix + one code fix. Hopefully the last beta release for 0.5.X. ftp://ftp.zresearch.com/pub/freeipmi/0.5.0.beta/ Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.5.1 Released
Downloadable at: http://www.gnu.org/software/freeipmi/download.html Release Notes: 0.5.1 - For Users - o Added previously missing IPMI 2.0 (-D LAN_2_0) support into ipmi-chassis, ipmi-fru, ipmi-sensors, ipmi-sel, ipmi-raw, and ipmimonitoring. o Added more strict IPMI over LAN implementation into ipmi-chassis, ipmi-fru, ipmi-sensors, ipmi-sel, ipmi-raw, and ipmimonitoring. o OpenIPMI and KCS Inband drivers will timeout after a certain period of time, so tools will no longer hang if the BMC is non-functional. o Ported IPMI compliance workarounds from ipmipower, ipmiconsole, and ipmimonitoring into ipmi-chassis, ipmi-fru, ipmi-sensors, ipmi-sel, and ipmi-raw. o Updated all manpages with more instructions, information, examples, and trouble shooting tips. o Support --debug option under the non-debug builds. o Rewrote error messages to provide more accurate descriptions. o Removed CALLBACK and OEM privilege capabilities in most tools. o Removed the quiet and silent options from bmc-config. o Added openipmi driver to bmc-watchdog. o Added keypair command line support to pef-config. o Removed bmc-autoconfig tool. o Added more details comments and instructions to bmc-config checkout. o Converted ipmiconsole, ipmipower, and ipmimonitoring to use argp instead of getopt for consistency of usage output. o Re-word ASUS 2.0 workaround into generic IGNORE SOL PAYLOAD SIZE workaround. o Support new IGNORE SOL PORT workaround. o Made many command line options, interactive prompt, and config file options consistent across FreeIPMI tools. Inconsistencies between dashes and underscores have been fixed in a number of places. Backwards compatability has been maintained when possible. Notable changes include: o --priv-level and --privilege options are now --privilege-level. o --auth-type options are now --authentication-type. o --reg-space or --register-space options are now --register-spacing. o --hostnames (plural) is now --hostname (not-plural). o --timeout is now --session-timeout. o --retry is now --retransmission. o All tools now use -W (--workarounds) to specify workarounds. o The plain authentication type is now the straight_password_key authentication type. o The short option -r for --register-spacing has been removed for consistency with other command line options. o Short options for most debugging options have been removed. o All -H and -h (help) options have been changed to -? for consistency in all tools. o All -v (version) options have been changed to -V for consistency with all tools. o The -T option and -I option in ipmipower have been flipped for consistency with other tools. o The -c option in ipmiconsole is now the -I option for consistency with other tools. o Short option -I changed to -D in bmc-watchdog for consistency with other tools. o The -i option in bmc-config is now the -c option. o The -k option in bmc-config and pef-config is now the -e option. o Various other minor bug fixes and enhancements. For Developers -- o Added IPMI 2.0 into UDM. o Added workaround support into UDM for IPMI 1.5 and IPMI 2.0. o Added IPMI 2.0 into the libipmimonitoring API. o Added scalability fixes into libipmiconsole for Conman. o Fix various library variable names and macros for consistency. Notable changes. 1) ipmi_ver_minor and ipmi_ver_major in struct ipmi_locate_info have been renamed to ipmi_version_minor and ipmi_version_major. 2) reg_space/register_space have been renamed to register_spacing globally. 3) privilege has been replaced to privilege_level globally. 4) Various library error codes have been renamed for consistency for error codes in other libraries. For example OUTMEM has been changed to OUT_OF_MEMORY globally. 5) Various error codes and messages have been renamed/redone to give more useful information. For example, IPMI_ERR_PRIVILEGE is now IPMI_ERR_PRIVILEGE_LEVEL_CANNOT_BE_OBTAINED and the error message has been updated appropriately. o Various bug fixes and enhancements. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] problem with freeipmi 0.5.3 and intel SE7221BK1-E
-acpi-spmi.c: 839: ipmi_acpi_get_rsdp: errno (9): expression failed ipmi-locate-acpi-spmi.c: 1034: ipmi_acpi_get_firmware_table: errno (9): expression failed ipmi-locate-acpi-spmi.c: 1239: ipmi_locate_acpi_spmi_get_dev_info: errno (9): expression failed Fetching SDR repository information... ipmi-kcs-api.c: 662: ipmi_kcs_write: errno (2): expression failed ipmi-kcs-api-udm.c: 74: ipmi_kcs_cmd_udm: errnum (10): expression failed SDR Cache creation failed: ipmi communication error I enabled the tracing and debug options after reading a few other emails of users with similar issues. I'd really like to get ipmi working on these servers so we can retrieve more details about the current hardware status. Does anyone have an idea what might be going wrong here? Chris ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] problem with freeipmi 0.5.3 and intel SE7221BK1-E
Hi Bala. Thank you for replying.
On Jan 16, 2008 11:10 PM, Bala.A [EMAIL PROTECTED] wrote:
Hi,
Please find inline replies
# ipmi-locate
Probing KCS device using DMIDECODE... FAILED
Probing SMIC device using DMIDECODE... FAILED
Probing BT device using DMIDECODE... FAILED
Probing SSIF device using DMIDECODE... done
IPMI Version: 1.5
IPMI locate driver: DMIDECODE
IPMI interface: SSIF
BMC driver device: /dev/i2c-0
BMC SMBUS slave address: 42
Register spacing: 1
Probing KCS device using SMBIOS... FAILED
Probing SMIC device using SMBIOS... FAILED
Probing BT device using SMBIOS... FAILED
Probing SSIF device using SMBIOS... done
IPMI Version: 1.5
IPMI locate driver: SMBIOS
IPMI interface: SSIF
BMC driver device: /dev/i2c-0
BMC SMBUS slave address: 84
Register spacing: 1
Please try the following commands and let me know they work or not
bmc-info --no-probing -D SSIF --driver-address=42
--driver-device=/dev/i2c-0 --register-spacing=1
bmc-info --no-probing -D SSIF --driver-address=84
--driver-device=/dev/i2c-0 --register-spacing=1
[EMAIL PROTECTED]:~# ls /dev/i2c*
/dev/i2c-0
[EMAIL PROTECTED]:~# lsmod | grep i2c
i2c_i801 10128 0
i2c_dev 8708 0
i2c_core 26112 2 i2c_i801,i2c_dev
[EMAIL PROTECTED]:~# lspci
00:00.0 Host bridge: Intel Corporation E7220/E7221 Memory Controller
Hub (rev 05)
00:02.0 VGA compatible controller: Intel Corporation E7221 Integrated
Graphics Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB UHCI #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC
Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW)
SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 03)
01:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
Ethernet Controller (rev 05)
02:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge A (rev 09)
02:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge B (rev 09)
04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
Ethernet Controller (rev 05)
[EMAIL PROTECTED]:~# bmc-info --no-probing -D SSIF --driver-address=42
--driver-device=/dev/i2c-0 --register-spacing=1
ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression failed
ipmi_cmd_get_device_id: permission denied
[EMAIL PROTECTED]:~# bmc-info --no-probing -D SSIF --driver-address=84
--driver-device=/dev/i2c-0 --register-spacing=1
ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression failed
ipmi_cmd_get_device_id: permission denied
Bala, FYI line 81 is a call to 'ipmi_ssif_write'.
errnum 4 in the ssif lib is IPMI_SSIF_CTX_ERR_PERMISSION.
the errnum seems to be set via this code chunk:
if (buf_len = IPMI_I2C_SMBUS_BLOCK_MAX)
{
count = ipmi_ssif_single_part_write (ctx-device_fd,
buf,
buf_len);
}
else
{
count = ipmi_ssif_multi_part_write (ctx-device_fd,
buf,
buf_len);
}
if (count 0)
{
if (errno == EACCES || errno == EPERM)
ctx-errnum = IPMI_SSIF_CTX_ERR_PERMISSION;
else
ERR_LOG(ctx-errnum = IPMI_SSIF_CTX_ERR_SYSTEM_ERROR);
goto cleanup;
}
tracing this into the deeper write calls, the errno is coming from the
core ioctl() call for ssif.
It looks like Chris is root above, so EACCES is not the likely returned
errno, EPERM = Operation Not Permitted is. So the question is why is
the ioctl not allowed.
Chris, does anything interesting show up in the 'dmesg' logs?
Al
Before trying this, please check /dev/i2c-0 device file is available or
not.
Thanks,
Regards,
Bala
---
Chris
___
Freeipmi-users mailing list
Freeipmi-users@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-users
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-users mailing list
Freeipmi-users@gnu.org
http://lists.gnu.org/mailman
Re: [Freeipmi-users] problem with freeipmi 0.5.3 and intel SE7221BK1-E
I don't think this would be a kernel related issue. Bala, you have any
ideas?
Al
Any more ideas? Have there been any important kernel changes that
should cause me to try to upgrade to 2.6.24?
Chris
On Jan 17, 2008 11:44 AM, Chris Morgan [EMAIL PROTECTED] wrote:
On Jan 17, 2008 11:36 AM, Albert Chu [EMAIL PROTECTED] wrote:
Hi Bala. Thank you for replying.
On Jan 16, 2008 11:10 PM, Bala.A [EMAIL PROTECTED] wrote:
Hi,
Please find inline replies
# ipmi-locate
Probing KCS device using DMIDECODE... FAILED
Probing SMIC device using DMIDECODE... FAILED
Probing BT device using DMIDECODE... FAILED
Probing SSIF device using DMIDECODE... done
IPMI Version: 1.5
IPMI locate driver: DMIDECODE
IPMI interface: SSIF
BMC driver device: /dev/i2c-0
BMC SMBUS slave address: 42
Register spacing: 1
Probing KCS device using SMBIOS... FAILED
Probing SMIC device using SMBIOS... FAILED
Probing BT device using SMBIOS... FAILED
Probing SSIF device using SMBIOS... done
IPMI Version: 1.5
IPMI locate driver: SMBIOS
IPMI interface: SSIF
BMC driver device: /dev/i2c-0
BMC SMBUS slave address: 84
Register spacing: 1
Please try the following commands and let me know they work or not
bmc-info --no-probing -D SSIF --driver-address=42
--driver-device=/dev/i2c-0 --register-spacing=1
bmc-info --no-probing -D SSIF --driver-address=84
--driver-device=/dev/i2c-0 --register-spacing=1
[EMAIL PROTECTED]:~# ls /dev/i2c*
/dev/i2c-0
[EMAIL PROTECTED]:~# lsmod | grep i2c
i2c_i801 10128 0
i2c_dev 8708 0
i2c_core 26112 2 i2c_i801,i2c_dev
[EMAIL PROTECTED]:~# lspci
00:00.0 Host bridge: Intel Corporation E7220/E7221 Memory Controller
Hub (rev 05)
00:02.0 VGA compatible controller: Intel Corporation E7221
Integrated
Graphics Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) PCI Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6
Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6
Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6
Family) USB UHCI #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6
Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC
Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW)
SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
SMBus Controller (rev 03)
01:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
Ethernet Controller (rev 05)
02:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge A (rev 09)
02:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
Bridge B (rev 09)
04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
Ethernet Controller (rev 05)
[EMAIL PROTECTED]:~# bmc-info --no-probing -D SSIF --driver-address=42
--driver-device=/dev/i2c-0 --register-spacing=1
ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression
failed
ipmi_cmd_get_device_id: permission denied
[EMAIL PROTECTED]:~# bmc-info --no-probing -D SSIF --driver-address=84
--driver-device=/dev/i2c-0 --register-spacing=1
ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression
failed
ipmi_cmd_get_device_id: permission denied
Bala, FYI line 81 is a call to 'ipmi_ssif_write'.
errnum 4 in the ssif lib is IPMI_SSIF_CTX_ERR_PERMISSION.
the errnum seems to be set via this code chunk:
if (buf_len = IPMI_I2C_SMBUS_BLOCK_MAX)
{
count = ipmi_ssif_single_part_write (ctx-device_fd,
buf,
buf_len);
}
else
{
count = ipmi_ssif_multi_part_write (ctx-device_fd,
buf,
buf_len);
}
if (count 0)
{
if (errno == EACCES || errno == EPERM)
ctx-errnum = IPMI_SSIF_CTX_ERR_PERMISSION;
else
ERR_LOG(ctx-errnum = IPMI_SSIF_CTX_ERR_SYSTEM_ERROR);
goto cleanup;
}
tracing this into the deeper write calls, the errno is coming from the
core ioctl() call for ssif.
It looks like Chris is root above, so EACCES is not the likely
returned
errno, EPERM = Operation Not Permitted is. So the question is why
is
the ioctl not allowed.
Chris, does
Re: [Freeipmi-users] ipmiconsole asus problem
Hey Bernd, Hello Al, On Sunday 23 March 2008, Albert Chu wrote: Hey Bernd, There are some ASUS ipmi compliance problems (confirmed by ASUS folks) but I don't know about if there are any firmware fixes out there. If you take a look at the manpage, under Workarounds you can find (currently) 3 workarounds I put into ipmiconsole for Asus motherboards (please let me know if your motherboard is not listed there, and I can add it to the list). The problem you're hitting below is almost assuredly the authcap issue. The solpayloadsize and solport are two others that may/may-not exist on your motherboard. thanks a lot for your help. Somehow I missed the authcap workaround, I alreay tried the sol*. In the end one has to specify -W authcap,solpayloadsize Great. Glad it works for you. This a RS162-E4/RX4 barebone and I think the mainboard is called DSBF-DR12/SAS (according to dmidecode). I'll add this one to the manpages. PLMK if those workarounds work out for you. Al P.S. If you/others are curious why ipmitool works by default, it's actually related to an architectural decision. Highlighted in part 8 of http://www.gnu.org/software/freeipmi/freeipmi-coding.txt. Which of these exactly? Wouldn't it be useful to simply try the authcap workaround if invalid user was returned? The workaround for the asus boards is to simply ignore the invalid user check early on and fall through to the remainder of the code. Unfortunately, I don't think there's any other way besides that :-( I still have a problem, though. As with ipmitool sysrqs don't work, although sysrqs are generally enabled. Do you have an idea what might be the problem? I can't speak for the asus boards, but I know that some motherboards cannot support serial-breaks via IPMI, therefore not allowing sysrqs to be generated. I only know of one vendor that does support it, and I had to complain until a firmware fix was finally done. So it wouldn't surprise me if serial-breaks via IPMI just didn't work on the asus board. Do sysrqs work when you connect via a normal serial cable? Al Thanks again for your help, Bernd -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmiconsole asus problem
Hello Al, On Sunday 23 March 2008, Albert Chu wrote: Hey Bernd, Hello Al, On Sunday 23 March 2008, Albert Chu wrote: Hey Bernd, I still have a problem, though. As with ipmitool sysrqs don't work, although sysrqs are generally enabled. Do you have an idea what might be the problem? I can't speak for the asus boards, but I know that some motherboards cannot support serial-breaks via IPMI, therefore not allowing sysrqs to be generated. I only know of one vendor that does support it, and I had to complain until a firmware fix was finally done. So it wouldn't surprise me if serial-breaks via IPMI just didn't work on the asus board. Do sysrqs work when you connect via a normal serial cable? I would be suprised if sysrqs via serial cable wouldn't work, so far this was never an issue with any system I ever tested. But I will make absolutely sure on Tuesday when I'm on site. We have an ipmi stability problem anyway and Asus is presently designing new ipmi cards (AFAIK some internal memory of these cards is too small to cache all sensors data and then the cards simply crash after some time), so I will tell them about the break problem... (I really need sysrqs, since I'm actually responsible for Lustre and the day will come when I need kernel traces to debug a Lustre problem). Thanks again for your help and happy Easter, Bernd Hey Bernd, Thanks for working with Asus on it. We use sysrqs here all the time for kernel traces/crashes/etc. The lack of its functionality by a lot of vendors in IPMI has worried us. Getting each vendor to be more IPMI compliant and get IPMI better will be good for all of us. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] request: status info for discrete sensors for monitoring purposes
Chassis intrusion] [System unplugged from LAN] Test case 2: wfisc...@wfischer-t410-ubuntu:~$ ipmitool -I lan -H 192.168.1.211 -U monitor -L user sdr get PS2 Status Password: Sensor ID : PS2 Status (0x71) Entity ID : 10.2 (Power Supply) Sensor Type (Discrete): Power Supply States Asserted : Power Supply [Presence detected] [Power Supply AC lost] Assertion Events : Power Supply [Presence detected] [Power Supply AC lost] Assertions Enabled: Power Supply [Presence detected] [Failure detected] [Predictive failure] [Power Supply AC lost] [Config Error: Vendor Mismatch] [Config Error: Revision Mismatch] [Config Error: Processor Missing] [Config Error] Deassertions Enabled : Power Supply [Presence detected] [Failure detected] [Predictive failure] [Power Supply AC lost] [Config Error: Vendor Mismatch] [Config Error: Revision Mismatch] [Config Error: Processor Missing] [Config Error] wfisc...@wfischer-t410-ubuntu:~$ ipmitool -I lan -H 192.168.1.211 -U monitor -L user sdr elist all | grep -i PS Password: PS1 AC Current | 78h | ok | 10.1 | 0.93 Amps PS2 AC Current | 79h | ok | 10.2 | 0.12 Amps PS1 +12V Current | 7Ah | ok | 10.1 | 16 Amps PS2 +12V Current | 7Bh | ok | 10.2 | 0 Amps PS1 +12V Power | 7Ch | ok | 10.1 | 192 Watts PS2 +12V Power | 7Dh | ok | 10.2 | 0 Watts PS1 Status | 70h | ok | 10.1 | Presence detected PS2 Status | 71h | ok | 10.2 | Presence detected, Power Supply AC lost wfisc...@wfischer-t410-ubuntu:~$ ipmitool -I lan -H 192.168.1.211 -U admin raw 0x04 0x2d 0x71 Password: Data length = 1 00 c0 09 00 wfisc...@wfischer-t410-ubuntu:~$ -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] request: status info for discrete sensors for monitoring purposes
Hi Werner, Currently I'm using ipmitool for the Nagios IPMI Sensor Monitoring Plugin www.*thomas-krenn.com/ipmi-plugin But it seems to me that ipmimonitoring from freeipmi has the benefit that it reports things like failed power supplies in a better way to parse it for a Nagios/Icinga plugin - I can just parse the fourth column and report OK back to Nagios/Icinga only when I get an Nominal there... So maybe I should write another version of the Plugin which uses ipmimonitoring instead of ipmitool... FYI, I wrote this plugin for Nagios awhile back. http://www.gnu.org/software/freeipmi/nagios_ipmimonitoring.pl Perhaps a decent place to start? (there'll be a new one when FreeIPMI 0.9.1 comes out, although I *think* it'll be forward compatible.) Al On Tue, 2010-06-22 at 14:28 -0700, Werner Fischer wrote: Hi Al - thank you for your valuable feedback again, On Tue, 2010-06-22 at 10:44 -0700, Albert Chu wrote: Hi Werner, Thanks. You are using a slightly older version of FreeIPMI (I can tell from the output format), so some of the comments below are related to newer versions. you are right, I use 0.7.15-2 which ships with Ubuntu 10.04 On Tue, 2010-06-22 at 04:16 -0700, Werner Fischer wrote: Hi Al, ipmimonitoring seems to be very useful for my needs. I gave it a try with an Intel SR2500 server. I unplugged one power chord from Power Supply 1 (PS1) and removed the cover of the cassis: ipmimonitoring reports Critical in the fourth column, which is great: wfisc...@wfischer-t410-ubuntu:~$ ipmimonitoring -h 192.168.1.211 -u monitor -p relation -l user | grep | Critical | 33 | Power Redundancy | Power Unit | Critical | N/A | 'Redundancy Lost' 'Non-redundant:Sufficient Resources from Redundant' 36 | Physical Scrty | Physical Security | Critical | N/A | 'General Chassis Intrusion' 49 | PS1 Status | Power Supply | Critical | N/A | 'Presence detected' 'Power Supply input lost (AC/DC)' wfisc...@wfischer-t410-ubuntu:~$ With ipmitool I got an ok for these sensors: wfisc...@wfischer-t410-ubuntu:~$ ipmitool -I lan -H 192.168.1.211 -U monitor -P relation -L user sdr elist [...] PS1 AC Current | 78h | ok | 10.1 | 0.12 Amps PS2 AC Current | 79h | ok | 10.2 | 0.93 Amps PS1 +12V Current | 7Ah | ok | 10.1 | 0 Amps PS2 +12V Current | 7Bh | ok | 10.2 | 16 Amps PS1 +12V Power | 7Ch | ok | 10.1 | 0 Watts PS2 +12V Power | 7Dh | ok | 10.2 | 192 Watts P1 Therm Margin | 99h | ok | 3.1 | -49 degrees C P2 Therm Margin | 9Bh | ok | 3.2 | -54 degrees C P1 Therm Ctrl % | C0h | ok | 3.1 | 0 unspecified P2 Therm Ctrl % | C1h | ok | 3.2 | 0 unspecified Proc 1 Vccp | D0h | ok | 3.1 | 1.23 Volts Proc 2 Vccp | D1h | ok | 3.2 | 1.23 Volts Mem Therm Margin | 48h | ns | 3.2 | No Reading Pwr Unit Stat| 01h | ok | 21.1 | Power Redundancy | 02h | ok | 21.1 | Redundancy Lost, Non-Redundant: Sufficient from Redundant BMC Watchdog | 03h | ok | 7.1 | Platform Secu V | 04h | ok | 7.1 | Physical Scrty | 05h | ok | 23.1 | General Chassis intrusion [...] Another test with ipmimonitoring, when PS1 is completely removed: wfisc...@wfischer-t410-ubuntu:~$ ipmimonitoring -h 192.168.1.211 -u monitor -p relation -l user | grep | Critical | 32 | Pwr Unit Stat | Power Unit | Nominal | N/A | 'OK' 33 | Power Redundancy | Power Unit | Critical | N/A | 'Redundancy Lost' 'Non-redundant:Sufficient Resources from Redundant' [...] 49 | PS1 Status | Power Supply | Nominal | N/A | 'OK' 50 | PS2 Status | Power Supply | Nominal | N/A | 'Presence detected' (Here ipmimonitoring says 'OK' in the last column, VMware says Unknown when a power supply is not installed - see http://**www.**wefi.net/shared/sr2500-example-1.png) It does depend on how the sensor is implemented. Here's a layman's idea of what a power supply sensor can report: A) sensor reading not available B) sensor reading available, reports nothing C) sensor reading available, reports presence detected D) sensor reading available, reports something wrong (e.g. AC lost) A, C, D map to obvious outputs (N/A vs presence detected vs AC input lost). B is the one that's hard to deal with. On some motherboards, reports nothing means the same as presence detected (the sensor reports A, B, or D, but not C). On some other motherboards reports nothing is the same as N/A (the sensor reports B, C, or D, but not A). I currently map reports nothing to OK, which is the same output as many other sensors. Thanks for this info. Not knowing much about the sensor
Re: [Freeipmi-users] request: status info for discrete sensors for monitoring purposes
Hi Werner, Do you have a approximate time plan when you expect version 0.9.1? I anticipated later this year, approximately Q4. If you're programming something against the ipmimonitoring tool, I wouldn't worry about it working with 0.9.1. It should be backwards compatible. I'll release FreeIPMI 0.9.1 w/ a ipmimonitoring script that will run the right options on ipmi-sensors to output the same output in 0.8.X. So you might want to check your eventual script against 0.8.X just in case. The output is pretty much the same, except the columns are aligned for easier readability. Al On Fri, 2010-06-25 at 00:54 -0700, Werner Fischer wrote: Hi Al, sorry for my late answer - I've been at OSDC and had the chance to talk about IPMI - I mentioned the possibilities of ipmimonitoring/freeipmi there ;-) http://*www.*thomas-krenn.com/de/wiki/Event-News:_OSDC_2010_The_Power_of_IPMI On Tue, 2010-06-22 at 14:36 -0700, Albert Chu wrote: Hi Werner, Currently I'm using ipmitool for the Nagios IPMI Sensor Monitoring Plugin www.**thomas-krenn.com/ipmi-plugin But it seems to me that ipmimonitoring from freeipmi has the benefit that it reports things like failed power supplies in a better way to parse it for a Nagios/Icinga plugin - I can just parse the fourth column and report OK back to Nagios/Icinga only when I get an Nominal there... So maybe I should write another version of the Plugin which uses ipmimonitoring instead of ipmitool... FYI, I wrote this plugin for Nagios a long time ago. http://*www.*gnu.org/software/freeipmi/nagios_ipmimonitoring.pl Perhaps a decent place to start? (there'll be a new one when FreeIPMI 0.9.1 comes out, although I *think* it'll be forward compatible.) Thank you for your tip. Although I'm not that good in Perl this is a good basis for me. Maybe I have time in about two weeks to write a first plugin-version (in the kind of our current plugin, based on bash/awk and support for verbository levels and so on) based on the current version of ipmimonitoring, that ships with RHEL/Ubuntu/Debian(Squeeze) - so that it works out of the box with these distributions. Once I have something in this area, I'll let you know on the mailinglist. Do you have a approximate time plan when you expect version 0.9.1? Thanks and best regards from Austria, Werner Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] bitbake recipe?
Hi Dick, I don't know of one personally. I know nothing about BitBake, other than the fact it is based on Gentoo's Portage. I know that FreeIPMI has been packaged for Gentoo, so I'm not sure if that's a good starting point or not. Al On Tue, 2010-07-06 at 10:41 -0700, dick.detwei...@emerson.com wrote: Hi all, I am wanting to include some of the freeipmi tools into an Open Embedded system. Is there a bitbake recipe out there already or will I need to generate one myself? Googled for it without success. Thanks, Dick Detweiler |Senior Software Engineer, MSD | Avocent | USA Emerson Network Power | 4991 Corporate Drive | Huntsville, AL 35805-6201 T 256.261.6550 | F 256.430.4027 www.*avocent.comhttp://*www.*avocent.com www.*emersonnetworkpower.com ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
RE: [Freeipmi-users] bitbake recipe?
On Tue, 2010-07-06 at 11:09 -0700, dick.detwei...@emerson.com wrote: Thanks for the response Al. I went ahead and started a recipe off of other similar packages in our environment. Configure is reporting this error: checking for /dev/urandom... configure: error: cannot check for file existence when cross compiling Is this something I can get around with an env variable or option passed into configure? Hmmm. This is definitely new to me. I can only assume it's something unique for your embedded environment (other folks that have done some embedded porting have not hit this). I could make a configure option to turn off checks for this. Al -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Tuesday, July 06, 2010 1:07 PM To: Detweiler, Dick [NETPWR/AVOCENT/AL] Cc: freeipmi-users@gnu.org Subject: Re: [Freeipmi-users] bitbake recipe? Hi Dick, I don't know of one personally. I know nothing about BitBake, other than the fact it is based on Gentoo's Portage. I know that FreeIPMI has been packaged for Gentoo, so I'm not sure if that's a good starting point or not. Al On Tue, 2010-07-06 at 10:41 -0700, dick.detwei...@emerson.com wrote: Hi all, I am wanting to include some of the freeipmi tools into an Open Embedded system. Is there a bitbake recipe out there already or will I need to generate one myself? Googled for it without success. Thanks, Dick Detweiler |Senior Software Engineer, MSD | Avocent | USA Emerson Network Power | 4991 Corporate Drive | Huntsville, AL 35805-6201 T 256.261.6550 | F 256.430.4027 www.**avocent.comhttp://**www.**avocent.com www.**emersonnetworkpower.com ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
RE: [Freeipmi-users] bitbake recipe?
Hey Dick, I implemented a --without-random-device option in ./configure. It's in the following beta release: http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.8.beta2.tar.gz Could you check it out and see if it works for you. Thanks, Al On Tue, 2010-07-06 at 11:57 -0700, dick.detwei...@emerson.com wrote: Hi all, Cross-posting to -devel since this issue hits how the configure script is written. FWIW, I'm finding some discussion about the use of the AC_CHECK_FILE macro in autoconf scripts. At the very end of configure.ac are two calls to AC_CHECK_FILE. This macro is written to produce an error if invoked while cross-compiling (which is what I am doing). Our build server does not have random or urandom but our target environment does. Wonder if this can be fixed by trying to find them on the staged target system? In the meantime, I'll see if we can't get random and urandom on our build machine. Thanks, Dick -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Tuesday, July 06, 2010 1:25 PM To: Detweiler, Dick [NETPWR/AVOCENT/AL] Cc: freeipmi-users@gnu.org Subject: RE: [Freeipmi-users] bitbake recipe? On Tue, 2010-07-06 at 11:09 -0700, dick.detwei...@emerson.com wrote: Thanks for the response Al. I went ahead and started a recipe off of other similar packages in our environment. Configure is reporting this error: checking for /dev/urandom... configure: error: cannot check for file existence when cross compiling Is this something I can get around with an env variable or option passed into configure? Hmmm. This is definitely new to me. I can only assume it's something unique for your embedded environment (other folks that have done some embedded porting have not hit this). I could make a configure option to turn off checks for this. Al -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Tuesday, July 06, 2010 1:07 PM To: Detweiler, Dick [NETPWR/AVOCENT/AL] Cc: freeipmi-users@gnu.org Subject: Re: [Freeipmi-users] bitbake recipe? Hi Dick, I don't know of one personally. I know nothing about BitBake, other than the fact it is based on Gentoo's Portage. I know that FreeIPMI has been packaged for Gentoo, so I'm not sure if that's a good starting point or not. Al On Tue, 2010-07-06 at 10:41 -0700, dick.detwei...@emerson.com wrote: Hi all, I am wanting to include some of the freeipmi tools into an Open Embedded system. Is there a bitbake recipe out there already or will I need to generate one myself? Googled for it without success. Thanks, Dick Detweiler |Senior Software Engineer, MSD | Avocent | USA Emerson Network Power | 4991 Corporate Drive | Huntsville, AL 35805-6201 T 256.261.6550 | F 256.430.4027 www.***avocent.comhttp://***www.***avocent.com www.***emersonnetworkpower.com ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 0.8.8 Released
http://ftp.gluster.com/pub/freeipmi/0.8.8/ FreeIPMI 0.8.8 - 07/20/10 - o Support Supermicro 'get-bmc-services-status' and 'set-bmc-services-status' in ipmi-oem. o Support bmc-watchdog 'ignorestateflag' workaround around more issues. o Support Open Session Privilege Workaround around more related compliance issues. o Fix bmc-watchdog --version option. o Fix legacy workaround corner case in channel detection for Intel nodes. o Support Quanta reset-to-defaults command in ipmi-oem. o Modify ipmiconsole protocol to not deactivate SOL protocol is SOL is already deactivated. o Modify ipmiconsole protocol to not error out under several malformed packet scenarios. o Fix ipmiping/rmcpping command line parsing corner case. o Minor documentation updates. o Minor error message output fixes. o Support --without-random-device configure option for some embedded systems. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] Re: ipmiconsole hangs at [SOL established]
Hi Amit, CCing freeipmi-users. I'm assuming you are trying to get an agetty prompt? I can think of two possible issues. 1) BIOS isn't redirecting serial data off the right COM port. It depends on your motherboard, but some motherboards require you to redirect off of COM2 instead of COM1. 2) The getty isn't redirecting through the right tty. e.g. maybe it should be tty1 instead of tty0. See /etc/inittab. Al On Tue, 2010-07-27 at 12:11 -0700, Amit Belani wrote: Hi Al, ipmiconsole hangs after displaying [SOL established], after having used the command ipmiconsole -h hostname -u username -p password -W solpayloadsize. Note that I get [error received]: BMC Implementation if I don't use -W solpayloadsize. Is there anything I can do to address this issue? I appreciate any help you can provide. If you need additional info from me, please let me know and I can send it to you. Thank you. -- Amit Belani Computer Operations Manager, NE-CAT, Cornell University Advanced Photon Source, Argonne National Laboratory 9700 S Cass Ave, Bldg. 436, E001, Argonne, IL 60439 abel...@anl.gov | desk: 630-252-0690 | mobile: 914-384-6366 -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Re: ipmiconsole hangs at [SOL established]
Hi Amit, On Wed, 2010-07-28 at 07:12 -0700, Amit Belani wrote: Al, Yes, I am trying to get an agetty prompt. I can use other FreeIPMI tools such as ipmipower just fine. Using --debug with ipmiconsole shows a continuous stream of scrollable text written to the screen after having received [SOL established] . I've no BIOS options to pick a COM port for IPMI redirection. /etc/inittab has mention of tty1 through tty6, but no mention of tty0. Sorry, I meant ttyS0 vs ttyS1. Usually people have a line in their inittab for respawning an agetty over serial. How do you usually setup/spawn your agetty? I suppose for testing purposes you can just run an agetty on the command line, e.g. agetty -L 115200 ttyS0 vs. agetty -L 115200 ttyS1 to see if an agetty can show up. Also, you may want to check the config output from bmc-config to see if the baud rate for the SOL is setup correctly. This may need to match the baud rate of your serial redirection too (most motherboards don't need it/require it, but maybe some do). Al Thanks. - Original Message - From: Albert Chu ch...@llnl.gov To: Amit Belani abel...@anl.gov Cc: freeipmi-users@gnu.org Sent: Tuesday, July 27, 2010 3:38:46 PM GMT -06:00 US/Canada Central Subject: Re: ipmiconsole hangs at [SOL established] Hi Amit, CCing freeipmi-users. I'm assuming you are trying to get an agetty prompt? I can think of two possible issues. 1) BIOS isn't redirecting serial data off the right COM port. It depends on your motherboard, but some motherboards require you to redirect off of COM2 instead of COM1. 2) The getty isn't redirecting through the right tty. e.g. maybe it should be tty1 instead of tty0. See /etc/inittab. Al On Tue, 2010-07-27 at 12:11 -0700, Amit Belani wrote: Hi Al, ipmiconsole hangs after displaying [SOL established], after having used the command ipmiconsole -h hostname -u username -p password -W solpayloadsize. Note that I get [error received]: BMC Implementation if I don't use -W solpayloadsize. Is there anything I can do to address this issue? I appreciate any help you can provide. If you need additional info from me, please let me know and I can send it to you. Thank you. -- Amit Belani -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmiping adversely affecting ipmitool
Hi Dick, On Sun, 2010-08-01 at 16:13 -0700, dick.detwei...@emerson.com wrote: Hello all, I am working on a multi-threaded app that searches a range of a IP addresses for IPMI devices and gathers info about any IPMI devices it finds. Just as an FYI, you're aware of FreeIPMI's 'ipmidetect' tool and daemon?? Not sure if that would be suitable for your needs. A thread is spun for each IP address to be searched. I am using ipmiping from the freeipmi suite to find them and ipmitool to get the info. I have isolated an interesting problem. If a thread for an IP address that will fail the ipmiping is included in the range, than other threads will from time to time fail getting information via ipmitool. The symptom is that the ipmitool request will return an OK status but there will be no data returned. If each thread is given 1 IP address to handle, but 1 thread's failure is affecting other threads, I'm not sure how this would be issue with ipmiping. Appears there is a threading issue. You could test this by setting up an easy program that spins threads that perform ipmiping, then if 1.5 or 2.0 are returned, send an fru print command using ipmitool, then echo or save the output to a file. I wonder if ipmiping is leaving the open-ipmi driver in a weird state so that when ipmitool runs its confused at times. I'm not sure why the open-ipmi kernel driver is involved here. If the ipmiping succeeds, are you doing the 'ipmitool' in-band? Anything out-of-band should not affect the kernel driver. Any ideas what this might be? I can only gather one guess. Some BMCs I've seen can get confused if they receive too many duplicate packets with duplicate sequence numbers and a short time span (DOS prevention? bug in firmware? BMC slow and can't handle so many packets simultaneously? Your guess is as good as mine). Depending on how you're doing the ipmiping or ipmitool, that could be an issue. Al Thanks, Dick Detweiler |Senior Software Engineer, MSD | Avocent | USA Emerson Network Power | 4991 Corporate Drive | Huntsville, AL 35805-6201 T 256.261.6550 | F 256.430.4027 www.*avocent.comhttp://*www.*avocent.com www.*emersonnetworkpower.com ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi support with HP iLO2 servers initial success!
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-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Re: FreeIPMI 1.0.1 Released
Hey John, I've added a section to the FAQ on the website to add a little bit of info to atleast point people in the right direction. There will also be some manpage updates in the next release. Thanks, Al On Thu, 2011-01-27 at 10:17 -0800, Albert Chu wrote: Hey John, I'll add something into the docs to give users hints on how to tell if their system has IPMI. Most users know from their product documentation. As for having the tools say if IPMI is supported on your system or not, it's unfortunately very difficult/impossible. The IPMI spec does not provide enough/define enough to make it possible. For example, I have several motherboards that do not give you *any* information that IPMI is available (discounting product manuals). Once FreeIPMI starts poking at default locations, it just happens to work. To contrast, I have seen some motherboards provide invalid information saying that IPMI is not supported, yet if the tools ignore this and try to communicate via IPMI anyways, it'll work. I'll see if I can add something better to handle your situation, but it's difficult to get something that can make FreeIPMI best for all situations. As for whether your motherboard supports IPMI, the below suggests its not supported since it cannot find any IPMI support info in various BIOS/SMBIOS/PCI locations [1]. Thanks, Al [1] - BTW, the 1.0.1 release of FreeIPMI does not output the default values by default (which I think confused people). I assume you installed FreeIPMI out of your distro, which may have had an older version. On Wed, 2011-01-26 at 19:33 -0800, John Gilmore wrote: I tried installing freeipmi on my system, but I can't get it working. I don't even know if my motherboard contains IPMI support. How can I tell? The FAQ doesn't say, the README doesn't say, the tools don't say, their man pages don't say what they do on a machine without IPMI. There's no obvious command to test whether this system implements IPMI. Please add some clarity to the documentation, for people who have no idea whether this hardware exists in their system or on their network. And possibly evolve the commands themselves so that they are clear about whether they see any IPMI hardware or not. The closest thing to diagnostic info that I can give you comes from: % sudo ipmi-locate Probing KCS device using DMIDECODE... FAILED Probing SMIC device using DMIDECODE... FAILED Probing BT device using DMIDECODE... FAILED Probing SSIF device using DMIDECODE... FAILED Probing KCS device using SMBIOS... FAILED Probing SMIC device using SMBIOS... FAILED Probing BT device using SMBIOS... FAILED Probing SSIF device using SMBIOS... FAILED Probing KCS device using ACPI... FAILED Probing SMIC device using ACPI... FAILED Probing BT device using ACPI... FAILED Probing SSIF device using ACPI... FAILED Probing KCS device using PCI... FAILED Probing SMIC device using PCI... FAILED Probing BT device using PCI... FAILED Probing SSIF device using PCI... FAILED KCS device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: KCS BMC driver device: BMC I/O base address: 0xCA2 Register spacing: 1 SMIC device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: SMIC BMC driver device: BMC I/O base address: 0xCA9 Register spacing: 1 BT device default values: SSIF device default values: IPMI Version: 1.5 IPMI locate driver: DEFAULT IPMI interface: SSIF BMC driver device: /dev/i2c-0 BMC SMBUS slave address: 0x42 Register spacing: 1 % So, does that mean I have hardware or not? No other command seems to do anything, e.g.: % sudo bmc-info ipmi_cmd_get_device_id: driver timeout % I did look for SMbus devices in lspci, and I have one: 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:07.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 13) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron
Re: [Freeipmi-users] Re: FreeIPMI 1.0.1 Released
Hey John, Good call, I hadn't thought of inputting a specific type to dmidecode, I always just grepped :-) I'll add that note to the FAQ. Thanks, Al On Thu, 2011-01-27 at 14:11 -0800, John Gilmore wrote: I've added a section to the FAQ on the website to add a little bit of info to atleast point people in the right direction. There will also be some manpage updates in the next release. Thank you for the FAQ update. In doing some more trolling around, I found this web page: http://www.cyberciti.biz/tips/querying-dumping-bios-from-linux-command-prompt.html which suggests that this command will dump info about an IPMI device, if it exists in the DMI: dmidecode --type 38 It also produces a sample printout of what such IPMI information might look like. You might want to put something similar into the FAQ, at least pointing out that if dmidecode produces an entry of type 38, it's likely that your motherboard has IPMI (but perhaps not the reverse). John -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] bmc-watchdog 0.7.15-2 exiting under Ubuntu 10.04
Hey Robert, That is indeed strange. Does the bmc-watchdog log say anything? (I can't remember the exact location, but I think it's /var/log/freeipmi/ something). Al On Thu, 2011-01-27 at 13:14 -0800, Robert Hardy wrote: I'm running bmc-watchdog 0.7.15-2 under a current Ubuntu 10.04 64 bit on several fairly new unloaded Supermicro servers. On only one (always the same server) of four servers the bmc-watchdog process quietly exits shortly after start up leaving the system setup for a hard reset shortly after bootup. The options and builds are identical on all of the servers. These are my options: OPTIONS=-d -u 2 -p 0 -a 1 -F -P -L -S -O -i 300 -e 60 Through debugging I've confirmed on boot up: - The init script gets run - It launches bmc-watchdog saves a new PID correctly in /var/run/bmc-watchdog.pid. - Checking for a bmc-watchdog process in rc.local shows it isn't running and the timer is counting down. - There is no shutdown message logged when the process disappears during bootup. - There are no messages suggesting the process was killed On shutdown the init script gets as far as removing /var/run/bmc-watchdog.pid and seems to work fine. If I stuff this in rc.local the bmc-watchdog starts up properly and never seems to die again until the next reboot: /usr/sbin/service bmc-watchdog stop /usr/sbin/service bmc-watchdog start All in all this is very weird behaviour. Is it possible a newer version of bmc-watchdog would address this? i.e. is this a known bug? Any other ideas why this is happening (or how I can debug further)? Regards, Rob ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] bmc-watchdog 0.7.15-2 exiting under Ubuntu 10.04
Hey Robert,
The following beta release has a bmc-watchdog that has (hopefully) fixed
logging.
http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.2.beta2.tar.gz
If you could check it out, that'd be great.
Al
On Tue, 2011-02-01 at 17:20 -0800, Albert Chu wrote:
Hi Robert,
On Tue, 2011-02-01 at 11:40 -0800, Robert Hardy wrote:
It is possible that there is a bios option which starts the watchdog
which is enabled.
Once I get a chance, I will dig around in the BIOS and see.
I think a more likely scenario would be the IPMI kernel driver is
starting up the watchdog and racing w/ the FreeIPMI one. Are you
loading the IPMI kernel driver?
I would think it would be much better behaviour on startup to do a
equivalent to bmc-watchdog -y then start the watchdog.
I had to look this up (b/c I couldn't remember, but was fairly certain)
the IPMI spec indicates that the watchdog timer is required to be turned
off when a node is rebooted (27.1).
Failing to start simply because the BIOS started the countdown seems
very very bad to me especially without logging anything.
The logging portion of this issue should be fixed w/ the next release.
You're left in
a state where the watchdog dies quietly and the server hard reboots
every couple of minutes.
If the BIOS happens to be starting the countdown, that's *REALLY* bad on
the part of the BIOS programmers. Whoever starts the countdown needs to
manage it. It can't be trusted for some other random piece of software
to handle.
So just so I understand the situation correctly, when you disable the
bmc-watchdog daemon, does the problem go away? The FreeIPMI
bmc-watchdog does not start any timer until it determines the timer is
stopped. Since the timer is already running, it never starts it.
Al
I'm willing to test anything you send my way. The server isn't really in
production yet but will be soon.
Ultimately I'm trying to package some better .debs for use on Ubuntu.
The current ones are badly packaged, to the point of of being unusable.
I've re-written the init script for Ubuntu but I'd really like to see an
upstart based one
Rob
On 2011-02-01 12:54 PM, Albert Chu wrote:
Hey Robert,
I think I see the problem(s). I call _err_exit(), which writes to
stderr, instead of _daemon_error_exit() which writes to the log. That's
the error logging issue, which is secondary to the real one.
As for the real issue, I think this is being hit:
if (timer_state == IPMI_BMC_WATCHDOG_TIMER_TIMER_STATE_RUNNING)
_err_exit (watchdog timer must be stopped before running daemon);
For some reason, your BMC think's the watchdog is running from the
start. You could verify w/ bmc-watchdog --get if if you don't star thte
timer. Perhaps it's a hardware bug?
As an experiment, would you be willing to try a beta that removed this
check? The issue is, I have no idea what the consequences of removing
this check will be on your motherboard if there's a bug in it.
Al
On Mon, 2011-01-31 at 15:11 -0800, Robert Hardy wrote:
That would be /var/log/freeipmi/bmc-watchdog.log here and nothing is
logged at startup (or after the unexpected exit) during bootup.
I've put all sorts of debugging lines in my init script for bmc-watchdog.
I finally ended up doing doing this at root:
mv /usr/sbin/bmc-watchdog /usr/sbin/bmc-watchdog.real
and then putting this in /usr/sbin/bmc-watchdog:
#!/bin/bash
strace -fFv -o /tmp/bmcstrace.log -- /usr/sbin/bmc-watchdog.real $@
At bootup the bmc-watchdog initscript does launch a process with a new
PID but it does NOT log the regular starting bmc-watchdog daemon. It
in fact logs nothing at all to /var/log/freeipmi/bmc-watchdog.log DURING
BOOT UP.
The strace above captured bmc-watchdog running at bootup and the same
process exiting here at the last few lines:
1584 semop(229383, {{0, 1, SEM_UNDO}}, 1) = 0
1584 nanosleep({0, 1000}, NULL)= 0
1584 write(2, bmc-watchdog.real: watchdog time..., 72) = -1 EBADF
(Bad file descriptor)
1584 exit_group(1) = ?
I've posted the entire strace here:
http://webcon.ca/~rhardy/bmcdrop/
Can you parse that and make any suggestions as to why it would exit
uncleanly and only on boot up?
I'm not quite sure what is going on, but it seems to be trying to write
on a bad file descriptor, getting an error and then exiting.
From the strace, file descriptor 2 is in fact closed so that error
makes sense to me. The real question is it trying to write to FD 2?
When I restart bmc-watchdog when it gets to the same place it properly
writes the startup message on file descriptor 0 which is the log file
which was opened earlier...
2466 write(0, [Jan 31 18:03:23]: starting bmc-..., 48) = 48
I'm open to debugging suggestions too
Re: [Freeipmi-users] error while loading shared libraries: libfreeipmi.so.10: cannot open shared object file: No such file or directory
I've added a little note to the README.build file about this. Al On Mon, 2011-02-14 at 10:18 -0800, Albert Chu wrote: Hi Lars, LD_LIBRARY_PATH and similar configuration (e.g. /etc/ld.so.conf) is something usually setup by your system automatically. I'm trying to figure out what is most commonly default on Linux boxes, but can't find a good answer. The fact you need to set that is not too surprising, but I don't know what is normal on Debian. I can put something in the FAQ about this for future folks. Al On Mon, 2011-02-14 at 08:55 -0800, larsen...@web.de wrote: Hi, I recently compiled freeipmi-1.0.1 on a Debian Lenny system with a simple ./configure make make install. When I tried to run /usr/local/sbin/ipmi-locate (or other tools) I got: /usr/local/sbin/ipmi-locate: error while loading shared libraries: libfreeipmi.so.10: cannot open shared object file: No such file or directory Searching the mailinglist, I found I had to export LD_LIBRARY_PATH=/usr/local/lib to get it to work. LD_LIBRARY_PATH was empty before. I couldn´t find anything in INSTALL or README about it. Is this supposed to be this way? Cheers Lars ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] FreeIPMI recognizes OEM sensor, but it does not return a reasonable state for it
Hi Lars, Indeed, not every OEM Event is mapped to a State reading. Many of the interpretations aren't added until a vendor adds it (or in my case, my company owns a motherboard and I put the interpretation in myself). If you can give me the following info, I can add the interpretation into FreeIPMI. bmc-info so I can get the manufacturer ID prodcut ID ipmi-sensors -vv --record-ids=74 so I can get the detailed event-reading type code and other information. Thanks, Al On Tue, 2011-02-15 at 09:09 -0800, larsen...@web.de wrote: Hi, I have a server where calling ipmimonitoring --interpret-oem-data returns ID | Name | Type | State | Reading | Units | Event 74 | SD vFlash Status | Module/Board | N/A | N/A | N/A | 'OK' So, the state is N/A while the event is OK. Perhaps, the state should also be OK? Please also see another mailinglist where this has already been discussed: http://lists.thomas-krenn.com/pipermail/ipmi-plugin-user/2011-February/000104.html Cheers Lars ~# ipmi-sensors -V ipmi-sensors - 1.0.1 ~# bmc-info Device ID : 32 Device Revision : 0 Device SDRs : supported Firmware Revision : 1.30 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : supported IPMB Event Generator : unsupported Bridge: supported Chassis Device: supported Manufacturer ID : Dell Inc. (674) Product ID: 256 Auxiliary Firmware Revision Information : 1800h GUID : 4A34524F-C0B9-5880-104A-004B4C4C4544 System Firmware Version : 1.2.1 System Name : Primary Operating System Name : Operating System Name : Channel Information Channel Number : 0 Medium Type : IPMB (I2C) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 1 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 2 Medium Type : Asynch. Serial/Modem (RS-232) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : single-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 3 Medium Type : System Interface (KCS, SMIC, or BT) Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 4 Medium Type : System Interface (KCS, SMIC, or BT) Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) ___ Freeipmi-users mailing list Freeipmi-users@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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Missing details on HP Proliant DL380 G7
Hi Nicola, I'll ping someone at HP I know that might be a bit more in the know. I'm sure the support person you talked to just has no idea what they're talking about :P Al On Sun, 2011-03-13 at 10:21 -0700, Nicola Pedrozzi wrote: Hello Albert, ping-ing HP didn't help, since I'm on Slackware, they just don't care. They said IPMI is based on SNMP and all the info should be there already. :^) they also said that you could just download their HPSIM package for Suse or Redhat and have a look in there , , I said: into the binaries Ok, just give up. I'll try to live with that .. ;^( , usually temperatures should be enough. FYI: . I flashed the BIOS firmware to the latest available . I tried recompiling the kernel with a default huge .configuration file from Slackware (that is, compiling many things that I'm not supposed to need) . I tried ipmitool-1.8.11 . I tried lm_sensors-3.2.0 Not much changed ... just once, ipmitool seemed to work but, at a second run, it started again complaining about Unable to open SDR for reading. I actually could not read all of the output because I used to many -vvv ... and my terminal scrolling (1500 lines) was not enough. I tried load/remove/reload/... many modules but I could not reproduce it. Thank you anyway and keep up with your great job, Bye nIc Albert Chu wrote: Great, it'll be fixed in FreeIPMI 1.0.3. Al On Fri, 2011-03-11 at 00:50 -0800, Nicola Pedrozzi wrote: Hi Al, thanks, bmc-info now works: # bmc-info Device ID : 19 Device Revision : 1 Device SDRs : supported Firmware Revision : 1.07 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : unsupported IPMB Event Generator : unsupported Bridge: unsupported Chassis Device: unsupported Manufacturer ID : Hewlett-Packard (11) Product ID: 8224 Channel Information Channel Number : 2 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 7 Medium Type : OEM Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) About OEM Sensors Id 0 and 1, I'll contact HP to see if they can provide some info. And maybe some more general specs on their IPMI implementation. Thanks for now, Bye nIc Albert Chu wrote: Hi Nicola, I just uploaded a beta of FreeIPMI 1.0.3 here: http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.3.beta0.tar.gz Could you give it a try to see if it runs bmc-info correctly? Thanks, Al On Thu, 2011-03-10 at 15:05 -0800, Albert Chu wrote: Hi Nicola, = Get System Info Parameters Response = KCS Header: [ 0h] = lun[ 2b] [ 7h] = net_fn[ 6b] IPMI Command Data: -- [ 59h] = cmd[ 8b] [ 80h] = comp_code[ 8b] ipmi_cmd_get_system_info_parameters_system_firmware_version_first_set: bad completion code I never handled this particular error code, so I can put in a fix to deal with this. I'll e-mail you a link to a beta tar.gz later on with the fix. Looking at the ipmi-sensors debug data, it seems legitimate. There's nothing to indicate that there should be more sensors. The sensors that report N/A are not available. If it's a bug on HP's part, that's on their firmware side and you'd have to ping them on that. One additional note: 0 | System Chassis 1 UID Light| OEM Reserved | N/A | N/A | 'OEM Event = h' 1 | System Chassis 2 Sys. Health LED | OEM Reserved | N/A | N/A | 'OEM Event = h' It'd be nice to support these OEM sensors. If you can ping HP and determine how to interpret these two sensors, I can add OEM interpretations into FreeIPMI for them. Al On Thu, 2011-03-10 at 14:11 -0800, Nicola Pedrozzi wrote: Hi Albert, first of all thanks for your prompt reply. The --entity-sensor-names helped a bit, but still some infos are missing, more specifically the RPM of the fans (there is space for 6 fans and correctly only the first 4 are showed because in my system config I only have 4, but I think somewhere there should also be the fans RPM of the 2 Power Supply...). Here the output with your suggested option: # ipmi-sensors
Re: [Freeipmi-users] Missing details on HP Proliant DL380 G7
| 'OK' 30 | Temp 17 | Temperature | 26.00 | C | 'OK' 31 | Temp 18 | Temperature | 30.00 | C | 'OK' 32 | Temp 19 | Temperature | 28.00 | C | 'OK' 33 | Temp 20 | Temperature | 27.00 | C | 'OK' 34 | Temp 21 | Temperature | 28.00 | C | 'OK' 35 | Temp 22 | Temperature | 32.00 | C | 'OK' 36 | Temp 23 | Temperature | 45.00 | C | 'OK' 37 | Temp 24 | Temperature | 29.00 | C | 'OK' 38 | Temp 25 | Temperature | 37.00 | C | 'OK' 39 | Temp 26 | Temperature | 41.00 | C | 'OK' 40 | Temp 27 | Temperature | 49.00 | C | 'OK' 41 | Temp 28 | Temperature | 73.00 | C | 'OK' 42 | Temp 29 | Temperature | 67.00 | C | 'OK' 43 | Temp 30 | Temperature | 37.00 | C | 'OK' 44 | Temp 31 | Temperature | 37.00 | C | 'OK' 45 | Temp 32 | Temperature | 32.00 | C | 'OK' 46 | Temp 33 | Temperature | N/A| C | N/A 47 | Temp 34 | Temperature | N/A| C | N/A 48 | Temp 35 | Temperature | N/A| C | N/A 49 | Temp 36 | Temperature | N/A| C | N/A 50 | Memory | Memory | N/A| N/A | 'Presence detected' 51 | Power Meter | Current | N/A| N/A | 'Device Enabled' --- I know ilo folks use ipmitool a lot for testing. I'm endeavoring for more comparison of other ipmi utilities as well (e.g. freeipmi). I had been meaning to mail about this difference (Fan/Power readings), so now I'll see if we can work out that issue. :) On Mon, Mar 14, 2011 at 10:41 AM, Albert Chu ch...@llnl.gov wrote: Hi Nicola, I'll ping someone at HP I know that might be a bit more in the know. I'm sure the support person you talked to just has no idea what they're talking about :P Al On Sun, 2011-03-13 at 10:21 -0700, Nicola Pedrozzi wrote: Hello Albert, ping-ing HP didn't help, since I'm on Slackware, they just don't care. They said IPMI is based on SNMP and all the info should be there already. :^) they also said that you could just download their HPSIM package for Suse or Redhat and have a look in there , , I said: into the binaries Ok, just give up. I'll try to live with that .. ;^( , usually temperatures should be enough. FYI: . I flashed the BIOS firmware to the latest available . I tried recompiling the kernel with a default huge .configuration file from Slackware (that is, compiling many things that I'm not supposed to need) . I tried ipmitool-1.8.11 . I tried lm_sensors-3.2.0 Not much changed ... just once, ipmitool seemed to work but, at a second run, it started again complaining about Unable to open SDR for reading. I actually could not read all of the output because I used to many -vvv ... and my terminal scrolling (1500 lines) was not enough. I tried load/remove/reload/... many modules but I could not reproduce it. Thank you anyway and keep up with your great job, Bye nIc Albert Chu wrote: Great, it'll be fixed in FreeIPMI 1.0.3. Al On Fri, 2011-03-11 at 00:50 -0800, Nicola Pedrozzi wrote: Hi Al, thanks, bmc-info now works: # bmc-info Device ID : 19 Device Revision : 1 Device SDRs : supported Firmware Revision : 1.07 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : unsupported IPMB Event Generator : unsupported Bridge: unsupported Chassis Device: unsupported Manufacturer ID : Hewlett-Packard (11) Product ID: 8224 Channel Information Channel Number : 2 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface
Re: [Freeipmi-users] Missing details on HP Proliant DL380 G7
Hey Chris, Looking at the code in ipmitool more closely, there are definitely checks for a discrete vs. non-discrete sensor, however implemented differently. Not incorrectly, just differently, which if the mobo vendor does not take into consideration, can lead to invalid output. I think this may be what's happening. UID Light| 0 unspecified | ok Sys. Health LED | 0 unspecified | ok Fan 1| 42.34 unspecifi | nc Fan 2| 42.34 unspecifi | nc Fan 3| 42.34 unspecifi | nc Fan 4| 42.34 unspecifi | nc It is likely these are not correct. At the minimum, there are no units. In addition, if this is a fan RPM sensor, 42.34 is likely very very wrong. If it is voltage, it is also very very wrong. Do these values even seem correct? Power Supply 1 | 170 Watts | nc Power Supply 2 | 155 Watts | nc Memory | 0 error | ok Power Meter | 462 Watts | cr These could possibly be correct, but if they are, it's a side effect. The event-reading-type code of these sensors is a discrete sensor, not a non-discrete sensor. So something is not good on the motherboard. Which version of ipmitool are you using? Also, is it the standard ipmitool released by a redhat/suse or perhaps one released by HP? Al On Tue, 2011-03-22 at 16:29 -0700, Albert Chu wrote: Hi Chris, Looking through the code in ipmitool really quick (not knowing the code as well and not having an HP machine on hand, it's hard to say for sure), it appears that the sdr command does not bother checking what if a sensor is a discrete sensor or non-discrete sensor. So it just always assumes the reading leads to a result. I could be wrong, but that's just skimming it. How does 'ipmitool sensor list' output compare to the 'ipmitool sdr' output? Al On Tue, 2011-03-22 at 15:52 -0700, Christopher Maestas wrote: Hello, One of the most recent things I found is that some readings come out on HP ilo3 with ipmitool versus freeipmi ... For example: # ipmitool -H HOST -U USER -P PASSWORD -I lanplus sdr UID Light| 0 unspecified | ok Sys. Health LED | 0 unspecified | ok Power Supply 1 | 170 Watts | nc Power Supply 2 | 155 Watts | nc Power Supply 3 | disabled | ns Power Supply 4 | disabled | ns Power Supplies | 0 unspecified | nc Fan 1| 42.34 unspecifi | nc Fan 2| 42.34 unspecifi | nc Fan 3| 42.34 unspecifi | nc Fan 4| 42.34 unspecifi | nc Fans | 0 unspecified | nc Temp 1 | 18 degrees C | ok Temp 2 | 45 degrees C | ok Temp 3 | 47 degrees C | ok Temp 4 | 46 degrees C | ok Temp 5 | 42 degrees C | ok Temp 6 | 35 degrees C | ok Temp 7 | 30 degrees C | ok Temp 8 | 32 degrees C | ok Temp 9 | 30 degrees C | ok Temp 10 | 32 degrees C | ok Temp 11 | 30 degrees C | ok Temp 12 | 31 degrees C | ok Temp 13 | 28 degrees C | ok Temp 14 | 30 degrees C | ok Temp 15 | 28 degrees C | ok Temp 16 | 32 degrees C | ok Temp 17 | 27 degrees C | ok Temp 18 | 30 degrees C | ok Temp 19 | 28 degrees C | ok Temp 20 | 28 degrees C | ok Temp 21 | 28 degrees C | ok Temp 22 | 32 degrees C | ok Temp 23 | 45 degrees C | ok Temp 24 | 29 degrees C | ok Temp 25 | 37 degrees C | ok Temp 26 | 41 degrees C | ok Temp 27 | 49 degrees C | ok Temp 28 | 73 degrees C | ok Temp 29 | 67 degrees C | ok Temp 30 | 37 degrees C | ok Temp 31 | 37 degrees C | ok Temp 32 | 32 degrees C | ok Temp 33 | disabled | ns Temp 34 | disabled | ns Temp 35 | disabled | ns Temp 36 | disabled | ns Memory | 0 error | ok Power Meter | 462 Watts | cr ipmi-sensors wasn't picking up this data ... --- # ipmi-sensors -h HOST ID | Name| Type | Reading| Units | Event 0 | UID Light | OEM Reserved | N/A| N/A | 'OEM Event = h' 1 | Sys. Health LED | OEM Reserved | N/A| N/A | 'OEM Event = h' 2 | Power Supply 1 | Power Supply | N/A| N/A | 'Presence detected' 3 | Power Supply 2 | Power Supply | N/A| N/A | 'Presence detected' 4 | Power Supply 3 | Power Supply | N/A| N/A | N/A 5 | Power Supply 4 | Power Supply | N/A| N/A | N/A 6 | Power Supplies | Power Supply | N/A| N/A | 'Fully
Re: [Freeipmi-users] Intel SR 1625 Sensors
Hey Werner, On Fri, 2011-04-01 at 10:15 -0700, Albert Chu wrote: Hi Werner, On Fri, 2011-04-01 at 03:51 -0700, Werner Fischer wrote: Hi Al, (sorry for sending it twice, I sent my first email in error only to you, not the list) I've been on vacation for some weeks and now back again. Benjamin meant with not detected that FreeIPMI returns a monitoring status of N/A for those sensors (not Nominal). Unfortunately we missed to send the output of ipmimonitoring --legacy-output --interpret-oem-data --quiet-cache --sdr-cache-recreate (which is used by our Nagios plugin): Record ID | Sensor Name | Sensor Group | Monitoring Status | Sensor Units | Sensor Reading [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | N/A | N/A | 'OK' 56 | P2 VRD Hot | Temperature | N/A | N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | N/A | N/A | 'OK' Would it be possible for you to include information about those four sensors to future versions of FreeIPMI, so that it reports a monitoring status of Nominal when the sensor reading is 'OK' as above? Shouldn't be a problem. B/c the SMI Timeout one is an OEM sensor, I would need information from Intel on that one. Actually, I would need info on Intel for one other sensor, #59. The discrete states for that sensor are asserted and deasserted. Naturally, these states are completely ambiguous. I can go ahead and add support into FreeIPMI for it, but the defaults I will have to completely guess on. Users might need to adjust the config file for their environment later on. [1] The other two temp sensors are limit exceeded vs limit not exceeded, so they are more clear. Al [1] - Unfortunately, this can't be avoid. One vendor's asserted could mean critical, while another vendor's asserted could be nominal. The other three I can figure out from the previous e-mail. Let me see what I can get for you to try out. Al In case you would need additional information from Intel about those sensors, just let me know. Best regards and have a nice weekend, thank you, Werner On Wed, 2011-02-23 at 10:06 -0800, Albert Chu wrote: Hi Benjamin, What do you mean by not detected? It appears everything is fine by the information you list below. Do you mean these sensors are not reporting actual temperatures? While these are indeed temperature sensors (identified by the motherboard as such), they do not appear to be sensors that report a temperature reading. They instead report an event bitmask. The key is the event/Readin Type Code field of each sensor. Al On Tue, 2011-02-22 at 23:55 -0800, Benjamin Bayer wrote: Hello, we have a Intel SR1625 wehre some Sensors not detected with FreeIPMI Version 1.0.2.beta3. Thank You. Regards Benjamin Bayer -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Intel SR 1625 Sensors
Hi Werner, On Fri, 2011-04-01 at 03:51 -0700, Werner Fischer wrote: Hi Al, (sorry for sending it twice, I sent my first email in error only to you, not the list) I've been on vacation for some weeks and now back again. Benjamin meant with not detected that FreeIPMI returns a monitoring status of N/A for those sensors (not Nominal). Unfortunately we missed to send the output of ipmimonitoring --legacy-output --interpret-oem-data --quiet-cache --sdr-cache-recreate (which is used by our Nagios plugin): Record ID | Sensor Name | Sensor Group | Monitoring Status | Sensor Units | Sensor Reading [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | N/A | N/A | 'OK' 56 | P2 VRD Hot | Temperature | N/A | N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | N/A | N/A | 'OK' Would it be possible for you to include information about those four sensors to future versions of FreeIPMI, so that it reports a monitoring status of Nominal when the sensor reading is 'OK' as above? Shouldn't be a problem. B/c the SMI Timeout one is an OEM sensor, I would need information from Intel on that one. The other three I can figure out from the previous e-mail. Let me see what I can get for you to try out. Al In case you would need additional information from Intel about those sensors, just let me know. Best regards and have a nice weekend, thank you, Werner On Wed, 2011-02-23 at 10:06 -0800, Albert Chu wrote: Hi Benjamin, What do you mean by not detected? It appears everything is fine by the information you list below. Do you mean these sensors are not reporting actual temperatures? While these are indeed temperature sensors (identified by the motherboard as such), they do not appear to be sensors that report a temperature reading. They instead report an event bitmask. The key is the event/Readin Type Code field of each sensor. Al On Tue, 2011-02-22 at 23:55 -0800, Benjamin Bayer wrote: Hello, we have a Intel SR1625 wehre some Sensors not detected with FreeIPMI Version 1.0.2.beta3. Thank You. Regards Benjamin Bayer -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Intel SR 1625 Sensors
Hey Werner, On Tue, 2011-04-05 at 23:47 -0700, Werner Fischer wrote: Hi Al, thank you for the beta. Sensors 55, 56, and 59 are now recognized: ID | Name | Type | State| Reading| Units | Event [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A| N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | Nominal | N/A| N/A | 'OK' 56 | P2 VRD Hot | Temperature | Nominal | N/A| N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | Nominal | N/A| N/A | 'OK' For sensor 47 the state is still N/A. For the SMI timeout I assume that the unasserted state is the one which should be nominal as I have found a notice on a similar Intel motherboard: There Intel they corrected an issue when SMI Timeout was asserted, causing a critical event in their event log - see page 19 in this pdf, point 5) Event Log may report SMI Timeout Assertion after Server Power button is pressed http://download.intel.com/support/motherboards/server/mfsys25/sb/mfsys25_mfsys35_spec_update_feb11.pdf Ahh, I completely misread sensor 47. I thought it was an OEM event sensor, but it's not. It has a normal event, the sensor type is the only thing that is OEM. Assuming your guess about assert vs. unassert is correct (it's a reasonable guess to me), I can add this OEM support into FreeIPMI. I'll try and get you a beta sometime later today. Al But I will ask Intel on more details on sensor 47 and sensor 59 as you have requested to be sure. I'll let you know on the list once I have more details on that. Best regards, Werner PS: here is some more verbose output on these four sensors: Record ID: 47 ID String: SMI Timeout Sensor Type: OEM Reserved (F3h) Sensor Number: 6 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 3h Sensor State: N/A Sensor Event: 'OK' Record ID: 55 ID String: P1 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 102 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 56 ID String: P2 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 103 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 2 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 59 ID String: IOH Therm Trip Sensor Type: Temperature (1h) Sensor Number: 106 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 3h Sensor State: Nominal Sensor Event: 'OK' On Fri, 2011-04-01 at 15:32 -0700, Albert Chu wrote: Hey Werner, Ben, Here's a beta that should support those sensor interpretations. It's tough for me to test w/o your motherboard in front of me, PLMK if it works for you. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.4.beta0.tar.gz Al On Fri, 2011-04-01 at 03:51 -0700, Werner Fischer wrote: Hi Al, (sorry for sending it twice, I sent my first email in error only to you, not the list) I've been on vacation for some weeks and now back again. Benjamin meant with not detected that FreeIPMI returns a monitoring status of N/A for those sensors (not Nominal). Unfortunately we missed to send the output of ipmimonitoring --legacy-output --interpret-oem-data --quiet-cache --sdr-cache-recreate (which is used by our Nagios plugin): Record ID | Sensor Name | Sensor Group | Monitoring Status | Sensor Units | Sensor Reading [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | N/A | N/A | 'OK' 56 | P2 VRD Hot | Temperature | N/A | N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | N/A | N/A | 'OK' Would it be possible for you to include information about those four sensors to future versions of FreeIPMI, so that it reports a monitoring status of Nominal when the sensor reading is 'OK' as above? In case you would need additional information from Intel about those sensors, just let me know. Best regards and have a nice weekend, thank you, Werner On Wed, 2011-02-23 at 10:06 -0800, Albert Chu wrote: Hi Benjamin, What do you mean by not detected? It appears everything is fine by the information you list below. Do you mean these sensors are not reporting actual temperatures? While
Re: [Freeipmi-users] Intel SR 1625 Sensors
Hey Werner, I got a beta release that should handle sensor #47. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.4.beta1.tar.gz Al On Wed, 2011-04-06 at 10:00 -0700, Albert Chu wrote: Hey Werner, On Tue, 2011-04-05 at 23:47 -0700, Werner Fischer wrote: Hi Al, thank you for the beta. Sensors 55, 56, and 59 are now recognized: ID | Name | Type | State| Reading| Units | Event [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A| N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | Nominal | N/A| N/A | 'OK' 56 | P2 VRD Hot | Temperature | Nominal | N/A| N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | Nominal | N/A| N/A | 'OK' For sensor 47 the state is still N/A. For the SMI timeout I assume that the unasserted state is the one which should be nominal as I have found a notice on a similar Intel motherboard: There Intel they corrected an issue when SMI Timeout was asserted, causing a critical event in their event log - see page 19 in this pdf, point 5) Event Log may report SMI Timeout Assertion after Server Power button is pressed http://download.intel.com/support/motherboards/server/mfsys25/sb/mfsys25_mfsys35_spec_update_feb11.pdf Ahh, I completely misread sensor 47. I thought it was an OEM event sensor, but it's not. It has a normal event, the sensor type is the only thing that is OEM. Assuming your guess about assert vs. unassert is correct (it's a reasonable guess to me), I can add this OEM support into FreeIPMI. I'll try and get you a beta sometime later today. Al But I will ask Intel on more details on sensor 47 and sensor 59 as you have requested to be sure. I'll let you know on the list once I have more details on that. Best regards, Werner PS: here is some more verbose output on these four sensors: Record ID: 47 ID String: SMI Timeout Sensor Type: OEM Reserved (F3h) Sensor Number: 6 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 3h Sensor State: N/A Sensor Event: 'OK' Record ID: 55 ID String: P1 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 102 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 56 ID String: P2 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 103 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 2 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 59 ID String: IOH Therm Trip Sensor Type: Temperature (1h) Sensor Number: 106 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 3h Sensor State: Nominal Sensor Event: 'OK' On Fri, 2011-04-01 at 15:32 -0700, Albert Chu wrote: Hey Werner, Ben, Here's a beta that should support those sensor interpretations. It's tough for me to test w/o your motherboard in front of me, PLMK if it works for you. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.4.beta0.tar.gz Al On Fri, 2011-04-01 at 03:51 -0700, Werner Fischer wrote: Hi Al, (sorry for sending it twice, I sent my first email in error only to you, not the list) I've been on vacation for some weeks and now back again. Benjamin meant with not detected that FreeIPMI returns a monitoring status of N/A for those sensors (not Nominal). Unfortunately we missed to send the output of ipmimonitoring --legacy-output --interpret-oem-data --quiet-cache --sdr-cache-recreate (which is used by our Nagios plugin): Record ID | Sensor Name | Sensor Group | Monitoring Status | Sensor Units | Sensor Reading [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | N/A | N/A | 'OK' 56 | P2 VRD Hot | Temperature | N/A | N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | N/A | N/A | 'OK' Would it be possible for you to include information about those four sensors to future versions of FreeIPMI, so that it reports a monitoring status of Nominal when the sensor reading is 'OK' as above? In case you would need additional information from Intel about those sensors, just let me know
Re: [Freeipmi-users] Intel SR 1625 Sensors
Hey Werner, Cool. I'll document this in the code as well, and I'll go ahead and write a SEL interpretation condition for the SMI timeout too. Al On Thu, 2011-04-07 at 07:06 -0700, Werner Fischer wrote: Hey Al, thanks for the beta1. I'll forward this to our customer and let you know as soon as I have feedback. btw: below are the details I got from Intel regarding the sensors. 1) SMI Timeout: The BMC supports an SMI timeout sensor (sensor type OEM (F3h), event type Discrete (03h)) that asserts if the SMI signal has been asserted for more than 90 seconds. A continuously asserted SMI signal is an indication that the BIOS cannot service the condition that caused the SMI. This is usually because that condition prevents the BIOS from running. When an SMI timeout occurs, the BMC asserts the SMI timeout sensor and logs a SEL event for that sensor. The BMC will also reset the system. The normal value is deasserted; system health status = OK When this sensor is asserted, the system health status = fatal. 2) IOH Therm Trip. This sensor indicates whether the IOH has reached overheating point (thermal trip point) The normal value is deasserted; system health status = OK When this sensor is asserted, the system health status = fatal. Both VRD Hot sensors have a fatal contribution to system health when in limit exceeded state. best regards, Werner On Wed, 2011-04-06 at 13:59 -0700, Albert Chu wrote: Hey Werner, I got a beta release that should handle sensor #47. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.4.beta1.tar.gz Al On Wed, 2011-04-06 at 10:00 -0700, Albert Chu wrote: Hey Werner, On Tue, 2011-04-05 at 23:47 -0700, Werner Fischer wrote: Hi Al, thank you for the beta. Sensors 55, 56, and 59 are now recognized: ID | Name | Type | State| Reading | Units | Event [...] 47 | SMI Timeout | OEM Reserved | N/A | N/A | N/A | 'OK' [...] 55 | P1 VRD Hot | Temperature | Nominal | N/A | N/A | 'OK' 56 | P2 VRD Hot | Temperature | Nominal | N/A | N/A | 'OK' [...] 59 | IOH Therm Trip | Temperature | Nominal | N/A | N/A | 'OK' For sensor 47 the state is still N/A. For the SMI timeout I assume that the unasserted state is the one which should be nominal as I have found a notice on a similar Intel motherboard: There Intel they corrected an issue when SMI Timeout was asserted, causing a critical event in their event log - see page 19 in this pdf, point 5) Event Log may report SMI Timeout Assertion after Server Power button is pressed http://download.intel.com/support/motherboards/server/mfsys25/sb/mfsys25_mfsys35_spec_update_feb11.pdf Ahh, I completely misread sensor 47. I thought it was an OEM event sensor, but it's not. It has a normal event, the sensor type is the only thing that is OEM. Assuming your guess about assert vs. unassert is correct (it's a reasonable guess to me), I can add this OEM support into FreeIPMI. I'll try and get you a beta sometime later today. Al But I will ask Intel on more details on sensor 47 and sensor 59 as you have requested to be sure. I'll let you know on the list once I have more details on that. Best regards, Werner PS: here is some more verbose output on these four sensors: Record ID: 47 ID String: SMI Timeout Sensor Type: OEM Reserved (F3h) Sensor Number: 6 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 3h Sensor State: N/A Sensor Event: 'OK' Record ID: 55 ID String: P1 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 102 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 56 ID String: P2 VRD Hot Sensor Type: Temperature (1h) Sensor Number: 103 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: processor (3) Entity Instance: 2 Entity Instance Type: Physical Entity Event/Reading Type Code: 5h Sensor State: Nominal Sensor Event: 'OK' Record ID: 59 ID String: IOH Therm Trip Sensor Type: Temperature (1h) Sensor Number: 106 IPMB Slave
Re: [Freeipmi-users] possible causes for ipmi_ctx_open_outofband: BMC busy
Hi Werner, The BMC Busy error code comes directly from the remote system. As you might imagine, it's typically when the BMC has too many IPMI requests to handle and can't handle all of them. That's the scenario I've personally seen them the most on. Al On Thu, 2011-04-21 at 02:15 -0700, Werner Fischer wrote: Hi Al, one of our customers monitors his Supermicro servers with FreeIPMI (with both Nagios using the plugin, and also using cacti). As both Nagios and cacti are monitoring the machines, it could be that two IPMI requests reach the BMC at the same time. For two systems (with X8DT3-LN4F and X8DTL-3F mainboards) he gets many times the following error: ipmi_ctx_open_outofband: BMC busy As it works for other systems, I assume that this could be a hardware problem. But I just wanted to know what the possibles reasons could be for such an error (BMC busy) Best regards, Werner PS: for the SR1625 question I got know feedback yet. I assume that the new beta works, but this customer can tell me for sure in about two weeks (than he can test the current beta) -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.0.4 Released
http://download.gluster.com/pub/freeipmi/1.0.4/ FreeIPMI 1.0.4 - 04/21/11 - o Support discretereading workaround in ipmi-sensors and associated libraries. o Support spinpoll workaround/performance optimization in tools and libraries. o Support additional sensor/SEL interpretations for Intel motherboards. o Add convenience input checking functions to libipmiconsole. o Fix bug in libipmimonitoring to allow additional OEM interpretations. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] IPMI questions
Hi Joe,
one can open a redirected console session and remotely mount media
(ISO images) on BIOS devices.
IPMI 2.0 supports serial-over-LAN (SOL), so if they implement their
redirected console session via it, FreeIPMI's ipmiconsole tool should be
a suitable cmdline tool equivalent. Depending on the default setup of
your motherboard, some additional config via FreeIPMI's bmc-config may
be necessary.
As for remotely mount media, it depends on what exactly you're looking
for. The following are available for configuration via FreeIPMI's
ipmi-chassis-config.
#
# Section Chassis_Boot_Flags Comments
#
# The following configuration options are for configuring chassis boot
behavior.
# Please note that some fields may apply to all future boots while some may
only
# apply to the next system boot.
#
# Boot_Flags_Persistent determines if flags apply to the next boot only or
all
# future boots.
#
# Boot_Device allows the user to configure which device the BIOS should boot
# off of. Most users may wish to select NO-OVERRIDE to select the configuration
# currently determined by the BIOS. Note that the configuration value
BIOS-SETUP
# refers to booting *into* the BIOS Setup, not from it. FLOPPY may refer to any
# type of removeable media. Device_Instance_Selector may be be used to select
# a specific device instance for booting.
#
Section Chassis_Boot_Flags
## Possible values: Yes/No (Yes = All Future Boots; No = Next Boot Only)
Boot_Flags_Persistent No
## Possible values: PC-COMPATIBLE/EFI
BIOS_Boot_TypePC-COMPATIBLE
## Possible values: Yes/No (Only applies to Next Boot)
CMOS_ClearNo
## Possible values: Yes/No (Only applies to Next Boot)
Lock_Keyboard No
## Possible values: Yes/No (Only applies to Next Boot)
Screen_Blank No
## Possible values: NO-OVERRIDE/PXE/HARD-DRIVE/HARD-DRIVE-SAFE-MODE/
## DIAGNOSTIC_PARTITION/CD-DVD/BIOS-SETUP/REMOTE-FLOPPY
##
PRIMARY-REMOTE-MEDIA/REMOTE-CD-DVD/REMOTE-HARD-DRIVE/FLOPPY
Boot_Device NO-OVERRIDE
## Possible values: None/Internal-{1-15}/External-{1-15} (e.g.
Internal-5)
Device_Instance_Selector None
## Possible values: Yes/No
Lock_Out_Reset_Button No
## Possible values: Yes/No
Lock_Out_Power_Button No
## Possible values: Yes/No
Lock_Out_Sleep_Button No
## Possible values: DEFAULT/QUIET/VERBOSE
Firmware_Bios_Verbosity DEFAULT
## Possible values: Yes/No
Force_Progress_Event_TrapsNo
## Possible values: Yes/No
User_Password_Bypass No
## Possible values: BIOS-SETTING/SUPPRESS/ENABLE
Console_Redirection BIOS-SETTING
EndSection
Beyond this, there isn't much in the IPMI spec mounting media.
Hope this helps,
Al
On Mon, 2011-04-25 at 18:03 -0700, joe mcguckin wrote:
Albert,
I recently purchased a Supermicro motherboard that has IPMI support. Using
the JAVA console app that you can get from
Supermicro, one can open a redirected console session and remotely mount
media (ISO images) on BIOS devices.
Are these two features proprietary extension of IPMI 2.0 - or - are they
implemented in the standard? For various reasons, I do not wish to use the
JAVA app to access the server remotely, I'd prefer a command line utility.
Supermicro has been less than useful in either making available a suitable
cmdline application, or protocol descriptions, etc for implementing our own.
Any help you can provide would be greatly appreciated.
Thanks,
Joe
Joe McGuckin
ViaNet Communications
j...@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-users mailing list
Freeipmi-users@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] HP ProLiant ML310 G5 does not support fan reading?
Hi Frantisek, Good timing, there should be a fix for you in 1.0.4 assuming it is the same issue that was seen on another HP motherboard. The workaround can be executed using the -W discretereading on the command line, or setting the flag permantently in freeipmi.conf. If it works for you, PLMK so I can your motherboard to FreeIPMI's documentation. (As a side note, on some HP motherboards, they tend to output percentage of fan max RPM, rather than the actual RPM.) The short story on the issue, the SDR records on the HP motherboard are messed up and list conflicting information. Whether intentional or a mistake, I don't know (perhaps they were trying to be clever and compacting information in a way they shouldn't have?). There's an HP fellow on this mailing list that is trying to get it sorted out in their firmware. Al On Tue, 2011-05-03 at 18:15 -0700, Frantisek Hanzlik wrote: I just tried freeipmi (0.8.8 and 1.0.4) on this small server. ipmi-sensors give output: ID | Name| Type | Reading| Units | Event 1 | Int. Health LED | OEM Reserved | N/A| N/A | 'OEM Event = h' 2 | VRM (CPU1) | Power Unit | N/A| N/A | 'Device Inserted/Device Present' 3 | CPU Fan | Fan | N/A| N/A | 'transition to Running' 4 | Rear Fan| Fan | N/A| N/A | 'transition to Running' 5 | Temp 1 | Temperature | 32.00 | C | 'OK' 6 | Temp 2 | Temperature | 30.00 | C | 'OK' 7 | Temp 3 | Temperature | 22.00 | C | 'OK' I'm surprised, as there are no fan rotation speed values, nor some other values, as if they were not available - N/A in Reading column. Although it is entry-level server, sensors for these values now have even cheapest desktops, I'm right? Is possible that server cannot measure these values, or may be there another problem? bmc-info display: Device ID : 17 Device Revision : 1 Device SDRs : supported Firmware Revision : 1.42 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : unsupported IPMB Event Generator : unsupported Bridge: unsupported Chassis Device: unsupported Manufacturer ID : Hewlett-Packard (11) Product ID: 0 Channel Information Channel Number : 7 Medium Type : OEM Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Thank in advance, Franta Hanzlík ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] HP ProLiant ML310 G5 does not support fan reading?
Hi Franta, Great. I don't believe the first two have readings, that's just the way they are. The HP fellow I know said he will try to figure out to interpret the OEM event of the first sensor. Until I get that info, all I can output is h. Thanks, Al On Wed, 2011-05-04 at 14:16 -0700, Frantisek Hanzlik wrote: Hello Al, You are right and Your fix is working, below is ipmi-sensors w/o and with -W discretereading option. First two ID's (Health LED and VRM) are still not displayed, but I not need them. Fan speeds in percentage of maximum doesn't matter, it's OK. Even lower is first part of dmidecode output, for better machine model identification. Many thanks for Your work! I see that project vitality has very high score, I wish You many further successes! Franta [root@mail log]# ipmi-sensors ID | Name| Type | Reading| Units | Event 1 | Int. Health LED | OEM Reserved | N/A| N/A | 'OEM Event = h' 2 | VRM (CPU1) | Power Unit | N/A| N/A | 'Device Inserted/Device Present' 3 | CPU Fan | Fan | N/A| N/A | 'transition to Running' 4 | Rear Fan| Fan | N/A| N/A | 'transition to Running' 5 | Temp 1 | Temperature | 32.00 | C | 'OK' 6 | Temp 2 | Temperature | 30.00 | C | 'OK' 7 | Temp 3 | Temperature | 22.00 | C | 'OK' [root@mail log]# ipmi-sensors -W discretereading ID | Name| Type | Reading| Units | Event 1 | Int. Health LED | OEM Reserved | N/A| N/A | 'OEM Event = h' 2 | VRM (CPU1) | Power Unit | N/A| N/A | 'Device Inserted/Device Present' 3 | CPU Fan | Fan | 60.37 | % | 'transition to Running' 4 | Rear Fan| Fan | 33.32 | % | 'transition to Running' 5 | Temp 1 | Temperature | 32.00 | C | 'OK' 6 | Temp 2 | Temperature | 30.00 | C | 'OK' 7 | Temp 3 | Temperature | 22.00 | C | 'OK' # # dmidecode 2.11 SMBIOS 2.4 present. 56 structures occupying 1594 bytes. Table at 0x000EE000. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: HP Version: W05 Release Date: 11/15/2007 Address: 0xF Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 5.25/360 kB floppy services are supported (int 13h) 5.25/1.2 MB floppy services are supported (int 13h) 3.5/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: HP Product Name: ProLiant ML310 G5 Version: Not Specified Serial Number: CZ1751005W UUID: 34343533-3336-435A-3137-353130303557 Wake-up Type: Power Switch SKU Number: 445336-421 Family: ProLiant Handle 0x0300, DMI type 3, 19 bytes Chassis Information Manufacturer: HP Type: Tower Lock: Not Present Version: Not Specified Serial Number: CZ1751005W Asset Tag: Boot-up State: Unknown Power Supply State: Unknown Thermal State: Unknown Security Status: Unknown OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Albert Chu wrote: Hi Frantisek, Good timing, there should be a fix for you in 1.0.4 assuming it is the same issue that was seen on another HP motherboard. The workaround can be executed using the -W discretereading on the command line, or setting the flag permantently in freeipmi.conf. If it works for you, PLMK so I can your motherboard to FreeIPMI's documentation. (As a side note, on some HP motherboards, they tend to output percentage of fan max RPM, rather than the actual RPM.) The short story on the issue, the SDR records on the HP motherboard are messed up and list conflicting information. Whether intentional or a mistake, I don't know
Re: [Freeipmi-users] Intel S3420GP invalid integrity check value
equivalent to the ipmitool command used above? In FreeIPMI, lanplus is equal to IPMI 2.0, so it'd be --driver-type=lan_2_0, -A is '-a', -H is -h, -U is -u, -P is -p, and -o is sort of like -W (depending on implementation). The 'sdr' command in ipmitool most closely resembles FreeIPMI's ipmi-sensors tool. Hope that helps, Al User, Lan conf and bmc-info output below. Cheers, Dave # bmc-config output Section User5 Usernameadmin Enable_User Yes Lan_Enable_IPMI_MsgsYes Lan_Enable_Link_AuthYes Lan_Enable_Restricted_to_Callback No Lan_Privilege_Limit Administrator SOL_Payload_Access Yes EndSection Section Lan_Conf IP_Address_Source Static IP_Address 192.168.0.50 MAC_Address 00:15:17:AD:D6:F4 Subnet_Mask 255.255.255.0 Default_Gateway_IP_Address 192.168.0.178 Default_Gateway_MAC_Address 00:E0:81:5F:E9:2E Backup_Gateway_IP_Address 0.0.0.0 Backup_Gateway_MAC_Address 00:00:00:00:00:00 Vlan_id 0 Vlan_Id_Enable No Vlan_Priority 0 EndSection # bmc-info Device ID : 33 Device Revision : 1 Device SDRs : unsupported Firmware Revision : 1.10 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : supported IPMB Event Generator : supported Bridge: unsupported Chassis Device: supported Manufacturer ID : Intel Corporation (343) Product ID: 62 Auxiliary Firmware Revision Information : 10012200h GUID : ----434D4249 System Firmware Version : rsion1.0 System Name : Manager Primary Operating System Name : SE Server 1.0 Operating System Name : Channel Information Channel Number : 0 Medium Type : IPMB (I2C) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 1 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 3 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 4 Medium Type : Asynch. Serial/Modem (RS-232) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : single-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 6 Medium Type : IPMB (I2C) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 7 Medium Type : System Interface (KCS, SMIC, or BT) Protocol Type: KCS Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Intel S3420GP invalid integrity check value
Hey David, On Wed, 2011-05-18 at 17:15 -0700, David Liontooth wrote: On 05/19/2011 01:02 AM, Albert Chu wrote: Some intel motherboards have a lot of IPMI non-compliance issues. In FreeIPMI, I'd suggest trying out some of the workarounds listed in the manpage. I currently see 3 Intel motherboards w/ workarounds available: intel20, opensesspriv, and integritycheckvalue that could be used w/ -W. (e.g. -W opensesspriv). Thanks! As I said, in this case it worked with ipmitool by removing -o intelplus. This also works: ipmi-sensors -D lan_2_0 -h bmc-ip -u admin -p pw -W opensesspriv -i ipmi-fru -D lan_2_0 -h bmc-ip -u admin -p pw -W opensesspriv Without the workaround, I get password invalid. The error messages in ipmi have to be taken with a grain of salt. Yeah, unfortunately there's not much I can do when the vendor implements something wrong. IIRC, in this case, the remote machine is reporting to the client invalid checks. Normally, this means the password was wrong, but in this motherboard's case, it's b/c they were doing a hash incorrectly. Can you set this up with a daemon and e-mail warnings? You mean like when sensors are out of whack? Or when a SEL entry reports an issue? Al Cheers, Dave What is the freeipmi equivalent to the ipmitool command used above? In FreeIPMI, lanplus is equal to IPMI 2.0, so it'd be --driver-type=lan_2_0, -A is '-a', -H is -h, -U is -u, -P is -p, and -o is sort of like -W (depending on implementation). The 'sdr' command in ipmitool most closely resembles FreeIPMI's ipmi-sensors tool. Hope that helps, Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Intel S3420GP invalid integrity check value
Hi David, On Thu, 2011-05-19 at 02:48 -0700, David Liontooth wrote: Hi Al, Thanks for the help! I've been wanting to get this working for several years ... On 05/19/2011 02:24 AM, Albert Chu wrote: The error messages in ipmi have to be taken with a grain of salt. Yeah, unfortunately there's not much I can do when the vendor implements something wrong. IIRC, in this case, the remote machine is reporting to the client invalid checks. Normally, this means the password was wrong, but in this motherboard's case, it's b/c they were doing a hash incorrectly. Sure, I gather there are a lot of quirks with this hardware. My main issue right now is that only one out of my seven Intel servers (five of them S3420GP) respond to impiping. In-band works fine on all of them, and I've used bmc-config to duplicate the configuration of the one working machine on the other S3420GP boxen, changing only IP and MAC addresses. I have a mix of public and private networks and udev reassignments of NICs, but the machine that works is no different in this respect from the others. Can I do something like nmap to see if the port is open? Using nmap should work to see if the port is open (or more notably, if you can nmap the IP you configure for IPMI. What is the minimal configuration needed for ipmiping to get a response? What could be causing the block? I just lucked out to have at least one working system, so at least I get to see how things should be behaving. It should simply be enabling IPMI (via Lan_Channel), configuring a proper IP, MAC, subnet, gateway, etc. If you're configuring an identical IP address as the host machine, it may be worth configuring a different one just to try. I've witnessed some motherboards not take a configuration until you hard-reset the node. Hard-reset meaning hitting the power button physically. Or you can cold-reset the BMC by running bmc-device --cold-reset to get the same affect. (I believe this is the equivalent of mc reset cold below) It's also possible there could be something in your BIOS affecting things. I've seen some motherboards have BIOS options for putting the ethernet card into certain modes which allow/not-allow IPMI. How can I reset and clear the configuration? I used ipmitool mc reset cold and it seemed to wipe the configuration (but not reboot the machine), but after a reboot it was back. As I said, I'm completely green to this and haven't found anyone on my campus willing and able to tell me what's going on. Some motherboards have factory reset capabilities, but they are manufacturer/OEM specific. I haven't come across one for Intel motherboards yet, so there aren't any in ipmi-oem yet. Can you set this up with a daemon and e-mail warnings? You mean like when sensors are out of whack? Or when a SEL entry reports an issue? This sort of thing -- customized criteria for automatic remote monitoring. I'm not there yet though, as I can't even ping. FreeIPMI doesn't have something that high level/specific at the moment (I've been thinking of writing one, but haven't had the time to). FreeIPMI currently has libraries/tools that are more for others to build upon for that feature. Al Cheers, Dave -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Dell OEM commands for setting fan thresholds?
Hi, The normal mechanism for configuring the fan thresholds is via the ipmi-sensors-config tool (see manpage for more details on how to config). It is possible the fields are read-only on your motherboard, so the tool may not work for you. If there is an OEM specific way to configure them, it might be hidden to end users and is only used by Dell during manufacturing. The Dell OEM commands in ipmi-oem came from some docs I got from Dell. The docs don't list a fan threshold modification, so I don't think I can help you on that front. Hope some of this information helps. Al On Wed, 2011-08-03 at 01:14 -0700, Arnuschky wrote: Hi, I would like to change the fan failure threshold of my Dell server. Unfortunately, they are read-only. The manual says that these values are not user-changeable, but are configured by your OEM. I think there might be IPMI commands for doing this - I doubt that they reflash the BMC bios when they start using different fan model. Is there anything like this? Where could I find out? Where did the Dell OEM commands specification come from? Cheers, Arnuschky ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] FreeIPMI on NetBSD (partial patch)
Hi Ben, On Sat, 2011-08-13 at 20:36 -0700, Ben C. wrote: Apologies for the cross posing here, the freeipmi-devel@ mailing list seems pretty dead. I probably should of posted In freeipmi-users@ to begin with. freeipmi-devel is alive and well, I just didn't check over the weekend. I finally got it to compile using this patch I made myself (kind of, thanks mostly to the NetBSD developer 'joerg' who wrote the asm* functions, I'm pretty sure he did.) http://pastebin.com/9mQpAuDZ In text: http://pastebin.com/raw.php?i=9mQpAuDZ I'm not sure why inb/outb aren't in your system to begin with. I'll have to let more BSD knowledgeable folks respond. However, it still doesn't work: # bmc-config --checkout could not find inband device I've tried various drivers and devices although they were either incorrect What do you mean by they were incorrect? Not working? Or reporting the wrong information? Was there any software provided by the vendor that at least minimally worked to show the system did indeed support IPMI? or freeipmi is broken in a way I do not understand nor how to fix. Assuming the inb/outb implementation you have is correct, there are a multitude of things that could be going on. Your system may not advertise the proper address to communicate with, so FreeIPMI is simply be trying defaults (which may not work). Lets start by seeing what is on your system. Can you run ipmi-locate, then run tools like dmidecode? (NetBSD's equivalent tool might be something different). There was some messages on the mailing lists about NetBSD support a year or two ago, -- I'm surprised it doesn't work 'out of the box' already. Others added NetBSD support into FreeIPMI, so I can't comment why it didn't work outright. NetBSD could have changed, or maybe they made an incorrect assumption, or a bug could have creeped in to. Al Anyone know the solution this time? Thanks, Ben On Sat, Aug 13, 2011 at 2:14 AM, Ben C. armon...@gmail.com wrote: Since there is no package in pkgsrc for FreeIPMI I have recently taken the task of building it the old fashioned way on my system. I've had quite a few issues-but this one, I'm stuck at. Right now my configure line looks something like this: ./configure LDFLAGS='-L/usr/pkg/lib/ -lpthread' CFLAGS='-I/usr/pkg/include/' Which ends with some errors (below). The only thing I can find related are build errors associated with an entirely different architecture, ppc64. Something about sys/io.h... glibc.. I'm really at a loss/over my head on this. Any ideas? I've also pastebin'd the entire clean/configure/make log if anyone has a moment to help: Paste: http://pastebin.com/UwTb3b6n Or, to view it without pastebin's ads, html, and other junk: http://pastebin.com/raw.php?i=UwTb3b6n Thanks, Ben --- [snip] *** Warning: Linking the executable bmc-config against the loadable module *** libfreeipmi.so is not portable! libtool: link: gcc -I/usr/pkg/include/ -o .libs/bmc-config bmc-config.o bmc-config-argp.o bmc-config-channel-common.o bmc-config-map.o bmc-config-sections.o bmc-config-utils.o bmc-config-user-sections.o bmc-config-lan-channel-section.o bmc-config-serial-channel-section.o bmc-config-lan-conf-section.o bmc-config-lan-conf-auth-section.o bmc-config-lan-conf-security-keys-section.o bmc-config-lan-conf-misc-section.o bmc-config-lan-conf-user-security-section.o bmc-config-rmcpplus-conf-privilege-section.o bmc-config-serial-conf-section.o bmc-config-pef-conf-section.o bmc-config-sol-conf-section.o bmc-config-misc-section.o bmc-config-validate.o -L/usr/pkg/lib/ ../../common/src/configtool/.libs/libconfigtoolcommon.a ../../common/src/toolcommon/.libs/libtoolcommon.a ../../common/src/toolhostrange/.libs/libtoolhostrange.a ../../common/src/miscutil/.libs/libmiscutils.a ../../common/src/parsecommon/.libs/libparsecommon.a ../../common/src/portability/.libs/libfreeipmiportability.a ../../libipmidetect/src/.libs/libipmidetect.so ../../libfreeipmi/src/.libs/libfreeipmi.so -L/usr/pkg/lib /usr/pkg/lib/libgcrypt.so /usr/pkg/lib/libgpg-error.so -lintl -lpthread -lm -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib ../../libfreeipmi/src/.libs/libfreeipmi.so: undefined reference to `inb' ../../libfreeipmi/src/.libs/libfreeipmi.so: undefined reference to `outb' *** Error code 1 Stop. make: stopped in /root/freeipmi-1.0.4/bmc-config/src *** Error code 1 Stop. make: stopped in /root/freeipmi-1.0.4/bmc-config *** Error code 1 Stop. make: stopped in /root/freeipmi-1.0.4 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi
Re: [Freeipmi-users] editing ipmi_monitoring_sensors.conf hangs ipmimonitoring
Hi Andrew, I had to dig deep b/c 0.5.1 is quite an old release (Dec 2007). The cause of this bug was fixed in 0.6.8. I'd recommend using the newer FreeIPMI's as there are many new enhancements, features, and bug fixes. However, since you are using the RHEL build of FreeIPMI, would you like to submit a bug to Redhat and have them fix the bug and make a new release? I could attach a patch to their ticket if they create one. Al On Wed, 2011-08-17 at 06:39 -0700, Andrew Hall wrote: After further investigation it has been noted that the following entry is where the strace halts - regardless of where it is in the config file: IPMI_Threshold_Sensor_At_Or_Above_Upper_Non_Critical_Threshold The version of freeipmi is 0.5.1 which still seems to be the latest and greatest that RHEL wish to release. Is this a known bug from this version ? ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] editing ipmi_monitoring_sensors.conf hangs ipmimonitoring
Hi Andrew, The other post should cover the bug and the fix, as for your other questions: 2. If I leave the file in the fully commented state as originally provided will the Monitoring Status values still obey those rules ? That is, are those conf file entries actually defaults that will function regardless of the fact they are commented out ? Yes, those are defaults that will function. 3. How can I determine the threshold values ? The output of ipmi-sensors shows NA for all readings in the Temperature group. The threshold values can typically be determined by running ipmi-sensors with more verbose output (using -v). As for your temperature readings being NA. It depends on your motherboard. Perhaps those temperatures sensors are OEM specific, therefore FreeIPMI can't read them. Or perhaps they are not available on your motherboard. Essentially it all boils down to this - is installing freeipmi and then running ipmisensors all that is required to determine potentially critical environmental issues ? For most motherboards, that is a sufficient way to determine environmental issues. A message along the lines of at or above critical will show up when appropriate. If the server gets too hot is this enough to find out ? Will it return Warning or Critical with no other manual intervention ? For Warning/Critical messages, you will need to use ipmimonitoring instead (for the 0.5.1 release you are using). In the newest FreeIPMI, you can still use ipmimonitoring, but ipmimonitoring is now a script that redirects to ipmi-sensors and the --output-sensor-state option. Al On Wed, 2011-08-17 at 03:49 -0700, Andrew Hall wrote: I wish to test the different Monitoring Status values that return when running the ipmimonitoring command. At the moment the monitoring status of Temperature is Nominal. I would like to ensure that if the sensor reading is over a particular threshold that it will return Warning or Critical. Rather than forcibly overheat the server I have edited ipmi_monitoring_sensors.conf as below: [user@server ~]# diff /etc/ipmi_monitoring_sensors.conf.orig /etc/ipmi_monitoring_sensors.conf 33c33 # IPMI_Threshold_Sensor_At_Or_Below_Lower_Non_Critical_Threshold Nominal --- IPMI_Threshold_Sensor_At_Or_Below_Lower_Non_Critical_Threshold Critical 36c36 # IPMI_Threshold_Sensor_At_Or_Above_Upper_Non_Critical_Threshold Nominal --- IPMI_Threshold_Sensor_At_Or_Above_Upper_Non_Critical_Threshold Critical So I have set two Nominal values to now read Critical. However when running the ipmimonitoring command after this change has been made it just sits there doing nothing. An strace show that it reads up to the newline character at the end of the second uncommented line in the config file but no further: read(3, C, 1) = 1 read(3, r, 1) = 1 read(3, i, 1) = 1 read(3, t, 1) = 1 read(3, i, 1) = 1 read(3, c, 1) = 1 read(3, a, 1) = 1 read(3, l, 1) = 1 read(3, \n, 1)= 1 So my questions are this: 1. Does anyone know why it is behaving in this manner ? 2. If I leave the file in the fully commented state as originally provided will the Monitoring Status values still obey those rules ? That is, are those conf file entries actually defaults that will function regardless of the fact they are commented out ? 3. How can I determine the threshold values ? The output of ipmi-sensors shows NA for all readings in the Temperature group. Essentially it all boils down to this - is installing freeipmi and then running ipmisensors all that is required to determine potentially critical environmental issues ? If the server gets too hot is this enough to find out ? Will it return Warning or Critical with no other manual intervention ? Thanks very much. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] RAC Status from DRAC5 on Dell Poweredge 1950
Hi Alexander, I remember seeing this before. Some of the Dell motherboards report illegal sensor events. I don't know if it is a bug on their motherboard or an intentional OEM extension (i.e. the events might be used for their Dell specific software). To deal with this, all you need to do is pass --ignore-unrecognized-events to ipmimonitoring. It will ignore the illegal events. Al On Tue, 2011-08-23 at 07:23 -0700, Alexander Fisher wrote: Hi All Hope you can help. I'm trying to use the check_ipmi_sensor nagios plugin I read about in 'Admin' magazine. It uses the freeipmi ipmimonitoring tool. I've so far tried to monitor two servers fitted with DRAC5 management cards, but one of the sensor readings is causing the plugin to exit with NAGIOS_CRITICAL. Here is the complete debug output from ipmimonitoring: Record ID: 51 Record Type: Compact Sensor Record (2h) ID String: RAC Status Sensor Type: Module/Board (15h) Sensor Number: 112 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 6Fh Sensor Direction: Unspecified Assertion Event Enabled: 'NONE' Deassertion Event Enabled: 'NONE' Share Count: 1 ID String Instance Modifier Type: Numeric ID String Instance Modifier Offset: 0 Entity Instance Sharing: Same for all records Sensor State: N/A Sensor Event: 'Unrecognized Event = 0001h' Sensor Event: 'Unrecognized Event = 0002h' Sensor Event: 'Unrecognized Event = 0004h' Does anybody know what the unrecognized events might mean? I think I can use the -x option in check_ipmi_sensor to hide the sensor, but i'm still interested in knowing what the sensor output means. Many thanks, Alex ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Freeipmi and SNMP community name
Hi George, You can find it in the ipmi-pef-config tool. Al On Thu, 2011-08-25 at 12:16 -0700, Hartlieb, George C. (ARC-AUS)[SCIENCE TECHNOLOGY CORP] wrote: Hi Al, I am configuring a Supermicro IPMI card and I cannot find where to configure the SNMP Community Name. The ipmitool command is this: ipmitool lan set 1 snmp community name Thanks for your help, George George Hartlieb System Administrator/Engineer Phone: 650-604-5690 george.hartl...@nasa.gov NASA Ames Research Center George Hartlieb (STC), Mail Stop 234-1 Bldg 234, Room 100 P.O. Box 1 Moffett Field, CA 94035-1001 -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.0.6 Released
http://download.gluster.com/pub/freeipmi/1.0.6/ FreeIPMI 1.0.6 - 09/01/11 - o Support 'ignorescanningdisabled' workaround in ipmi-sensors. o Support Supermicro X8SIL-F, X9SCL, and X9SCM motherboard OEM sensors. o Update bmc-watchdog logrotate script to reduce unnecessary output. o Fix ipmi-fru output typo. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Send Message using FreeIPMI
Hi Phil, Are you trying to program a raw command via libfreeipmi? What problems are you having? It's sort of hard to describe a raw command to do it, since one normally uses it to encapsulate another command for bridging, and its dependent on the channel and addresses you're sending to. Here's an example of a send message, bridging a sensor read, on a motheboard I have. ipmi-raw 0 6 0x34 0x06 0x2c 0x10 0xc4 0x20 0x4e 0x2d 0x1a 0x4b Here's the packet I created it from. = Send Message Request = KCS Header: [ 0h] = lun[ 2b] [ 6h] = net_fn[ 6b] IPMI Command Data: -- [ 34h] = cmd[ 8b] [ 6h] = channel_number[ 4b] [ 0h] = send_message_with_authentication[ 1b] [ 0h] = send_message_with_encryption[ 1b] [ 0h] = tracking_operation[ 2b] IPMB Message Header: [ 2Ch] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 4h] = net_fn[ 6b] [ C4h] = checksum1[ 8b] [ 20h] = rq_addr[ 8b] [ 2h] = rq_lun[ 2b] [ 13h] = rq_seq[ 6b] IPMB Message Data: -- [ 2Dh] = cmd[ 8b] [ 1Ah] = sensor_number[ 8b] IPMB Message Trailer: - [ 4Bh] = checksum2[ 8b] Al On Sun, 2011-09-11 at 13:19 -0700, phil_chides...@dell.com wrote: I am trying to do a IPMI Send Message Command using Free IPMI but having problems. Can someone send the RAW format for the IPMI Send Message Command? Phil Chidester Storage Engineering Dell | PG Development 512 728-4840 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Send Message using FreeIPMI
Hi Phil, On Mon, 2011-09-12 at 13:48 -0700, phil_chides...@dell.com wrote: Hi Al, Thanks for the quick response. I am using a similar command to yours however I am getting : Unable to send command: Invalid argument I assume this is from ipmitool, can't really say why that error would occur there. What I am doing is having two BMCs talk to each other over IPMB. Currently both addresses are 0x20 however. I tried this command as well for bridging sdrs : ipmitool -m 0x20 -t 0x20 sdr However it just returned the host sdr not the peer sdr. Do I need to change the address of the peer controller to something besides 0x20 and provide a SRC Type 12 (Management Controller Device Locator Record)? I'm not an expert on IPMB, but my gut feeling is you need to change the address of the peer. How else would a controller know to forward the command somewhere else? Al Thanks in advance, Phil Chidester Storage Engineering Dell | PG Development 512 728-4840 -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Monday, September 12, 2011 12:48 PM To: Chidester, Phil Cc: freeipmi-users@gnu.org Subject: Re: [Freeipmi-users] Send Message using FreeIPMI Hi Phil, Are you trying to program a raw command via libfreeipmi? What problems are you having? It's sort of hard to describe a raw command to do it, since one normally uses it to encapsulate another command for bridging, and its dependent on the channel and addresses you're sending to. Here's an example of a send message, bridging a sensor read, on a motheboard I have. ipmi-raw 0 6 0x34 0x06 0x2c 0x10 0xc4 0x20 0x4e 0x2d 0x1a 0x4b Here's the packet I created it from. = Send Message Request = KCS Header: [ 0h] = lun[ 2b] [ 6h] = net_fn[ 6b] IPMI Command Data: -- [ 34h] = cmd[ 8b] [ 6h] = channel_number[ 4b] [ 0h] = send_message_with_authentication[ 1b] [ 0h] = send_message_with_encryption[ 1b] [ 0h] = tracking_operation[ 2b] IPMB Message Header: [ 2Ch] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 4h] = net_fn[ 6b] [ C4h] = checksum1[ 8b] [ 20h] = rq_addr[ 8b] [ 2h] = rq_lun[ 2b] [ 13h] = rq_seq[ 6b] IPMB Message Data: -- [ 2Dh] = cmd[ 8b] [ 1Ah] = sensor_number[ 8b] IPMB Message Trailer: - [ 4Bh] = checksum2[ 8b] Al On Sun, 2011-09-11 at 13:19 -0700, phil_chides...@dell.com wrote: I am trying to do a IPMI Send Message Command using Free IPMI but having problems. Can someone send the RAW format for the IPMI Send Message Command? Phil Chidester Storage Engineering Dell | PG Development 512 728-4840 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Send Message using FreeIPMI
On Mon, 2011-09-12 at 14:19 -0700, phil_chides...@dell.com wrote: Hi Al, Sorry the error for ipmi-raw was : ipmi_cmd_raw: internal error Do you know what causes that error or if there is a more verbose option in impi_raw? Internal errors are the odd errors that can't be handled. If you compile FreeIPMI w/ the configure options --enable-debug and --enable-trace, we can get a lot more information. Al I was assuming it would just route it on the IPMI bus at address 0x20 and not do a check on the address. Thanks, Phil -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Monday, September 12, 2011 4:11 PM To: Chidester, Phil Cc: freeipmi-users@gnu.org Subject: RE: [Freeipmi-users] Send Message using FreeIPMI Hi Phil, On Mon, 2011-09-12 at 13:48 -0700, phil_chides...@dell.com wrote: Hi Al, Thanks for the quick response. I am using a similar command to yours however I am getting : Unable to send command: Invalid argument I assume this is from ipmitool, can't really say why that error would occur there. What I am doing is having two BMCs talk to each other over IPMB. Currently both addresses are 0x20 however. I tried this command as well for bridging sdrs : ipmitool -m 0x20 -t 0x20 sdr However it just returned the host sdr not the peer sdr. Do I need to change the address of the peer controller to something besides 0x20 and provide a SRC Type 12 (Management Controller Device Locator Record)? I'm not an expert on IPMB, but my gut feeling is you need to change the address of the peer. How else would a controller know to forward the command somewhere else? Al Thanks in advance, Phil Chidester Storage Engineering Dell | PG Development 512 728-4840 -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Monday, September 12, 2011 12:48 PM To: Chidester, Phil Cc: freeipmi-users@gnu.org Subject: Re: [Freeipmi-users] Send Message using FreeIPMI Hi Phil, Are you trying to program a raw command via libfreeipmi? What problems are you having? It's sort of hard to describe a raw command to do it, since one normally uses it to encapsulate another command for bridging, and its dependent on the channel and addresses you're sending to. Here's an example of a send message, bridging a sensor read, on a motheboard I have. ipmi-raw 0 6 0x34 0x06 0x2c 0x10 0xc4 0x20 0x4e 0x2d 0x1a 0x4b Here's the packet I created it from. = Send Message Request = KCS Header: [ 0h] = lun[ 2b] [ 6h] = net_fn[ 6b] IPMI Command Data: -- [ 34h] = cmd[ 8b] [ 6h] = channel_number[ 4b] [ 0h] = send_message_with_authentication[ 1b] [ 0h] = send_message_with_encryption[ 1b] [ 0h] = tracking_operation[ 2b] IPMB Message Header: [ 2Ch] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 4h] = net_fn[ 6b] [ C4h] = checksum1[ 8b] [ 20h] = rq_addr[ 8b] [ 2h] = rq_lun[ 2b] [ 13h] = rq_seq[ 6b] IPMB Message Data: -- [ 2Dh] = cmd[ 8b] [ 1Ah] = sensor_number[ 8b] IPMB Message Trailer: - [ 4Bh] = checksum2[ 8b] Al On Sun, 2011-09-11 at 13:19 -0700, phil_chides...@dell.com wrote: I am trying to do a IPMI Send Message Command using Free IPMI but having problems. Can someone send the RAW format for the IPMI Send Message Command? Phil Chidester Storage Engineering Dell | PG Development 512 728-4840 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://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-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] No SDR values from ipmi-sensors on Fujitsu RX300 and RX300S2
/ipmi-sensors/src $ Which information should I provide to track the bug? Kind regards, omo ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] No SDR values from ipmi-sensors on Fujitsu RX300 and RX300S2
Hey Olaf, Great! Glad it work. i.e. sensor IDs 2624 an 2672 say that FAN SYS5 and FAN PS1 are present, but sensor IDs 1728 and 1792 show a RPM value of 0. In fact, both fans are not present This is likely a fallout from the Fujitsu BMC implementation. I've seen this on other motherboards too. It appears that some sensor controllers default to some good value (e.g. entity present) and only report an error (e.g. not present) when an error occurs. This is regardless if the device is there or not. Naturally, for an entity presence sensor its particular annoying/doesn't make sense. Al On Mon, 2011-09-19 at 01:43 -0700, Olaf Morgenstern wrote: I forgot to CC to the list, so this is to make up my mistake... Hi Al, thank you for the beta release. It works! As you can see in the attached outputs (no cache flush issued before), the sensors are read fine. The only difference to version 0.5.1 is the output of the OEM values. But this values seem to be broken, i.e. sensor IDs 2624 an 2672 say that FAN SYS5 and FAN PS1 are present, but sensor IDs 1728 and 1792 show a RPM value of 0. In fact, both fans are not present, because the redundant sys fan option (FAN SYS3 to SYS5) is not built in, and there is only one power supply (the redundant second power supply PS1 is not built in). If you look at the OEM values for the SYS and PS fans (IDs 2720, 2768, 2816, 2864, 2912, 2960, 3008, 3056) you can see different values for the present and the absent ones. But this is not your problem, it's the Fujitsu BMC/IPMI implementation... So, -W assumebmcowner helps on the old Fujitsu hardware. Tested on RX300 and RX300S2. It should work on the following Fujitsu server hardware with the so called Kalypso-BMC: – RX200 / TX200 (mainboard D1570 / D1419) – RX220 (mainboard D2130) – RX300 / TX300 (mainboard D1409 / D1409) – RX100 S2 (mainboard D1571) – RX200 S2 / TX200 S2 (mainboard D1790 / D1919) – RX300 S2 / TX300 S2 (mainboard D1889/D2089 / D1899/D2099) – RX100 S3 (mainboard D2004) – TX150 S2 (mainboard D1751) – TX150 S3 (mainboard D1979) – TX150 S4 (mainboard D2239) Regards, Olaf Original-Nachricht Datum: Thu, 15 Sep 2011 14:17:01 -0700 Von: Albert Chu ch...@llnl.gov An: Olaf Morgenstern mistkerl...@gmx.de CC: freeipmi-users@gnu.org freeipmi-users@gnu.org Betreff: Re: [Freeipmi-users] No SDR values from ipmi-sensors on Fujitsu RX300 and RX300S2 Hey Olaf, Here is a beta release http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.7.beta2.tar.gz In it, ipmi-sensors has a new workaround option called 'assumebmcowner', can you see if it works? Just specify: ipmi-sensors -W assumebmcowner (longer term, you can configure this workaround in /etc/freeipmi.conf so you don't have to type it everytime. But for now ...) Can you try it and let me know if the workaround works for you. Thanks, Al On Thu, 2011-09-15 at 09:00 -0700, Al Chu wrote: Huh ... but it does work w/ 0.5.1. Ya know, maybe your SDR is just buggy. Even though it advertises that it wants to bridge sensors, in reality, it shouldn't. Back in 0.5.1, ipmi-sensors wasn't as correct/valid, so bridging wasn't handled properly. Let me get you a beta tar.gz with a workaround option to try out and see if that helps. Al On Thu, 2011-09-15 at 04:39 -0700, Olaf Morgenstern wrote: Hi Al, as promised, the debug output from ipmi-sensors v0.5.1, once after a cache flush and once from a filled cache. Don't wonder about the different IP address, it's still a RX300 which was queried. The reason is that I can't query the IPMI LAN interface of the same machine running ipmi-sensors (it's a Broadcom LAN interface and BMC). Thanks, Olaf Original-Nachricht Datum: Wed, 14 Sep 2011 07:47:16 -0700 Von: Al Chu ch...@llnl.gov An: mistkerl...@gmx.de mistkerl...@gmx.de CC: freeipmi-users@gnu.org freeipmi-users@gnu.org Betreff: Re: [Freeipmi-users] No SDR values from ipmi-sensors on Fujitsu RX300 and RX300S2 Hi, First, could run the following ipmi-sensors -f to flush out the old SDR cache and try ipmi-sensors again (it'll reload the SDR cache). I'm wondering if there was an SDR format change between versions that is not being caught. Although I've personally never seen it before, you may want to try the --bridge-sensors option. It's possible all your motherboard's sensors aren't owned by the BMC. If that doesn't work, could you send me the ipmi-sensors output w/ --debug. Thanks, Al On Tue, 2011-09-13 at 23:57 -0700, mistkerl...@gmx.de wrote: I want to monitor my Fujitsu servers with the check-ipmi-sensor plugin (v2) for Nagios. It requires the ipmimonitoring tool from freeipmi. I tried
Re: [Freeipmi-users] Can't get freeipmi_interpret_sensor.conf to work
| N/A| RPM | N/A 473 | FAN 8 | Fan | N/A| RPM | N/A 540 | CPU1 Vcore| Voltage | 1.01 | V | 'OK' 607 | CPU2 Vcore| Voltage | 1.10 | V | 'OK' 674 | +1.5 V| Voltage | 1.52 | V | 'OK' 741 | +5 V | Voltage | 5.09 | V | 'OK' 808 | +5VSB | Voltage | 5.06 | V | 'OK' 875 | +12 V | Voltage | 12.19 | V | 'OK' 942 | CPU1 DIMM | Voltage | 1.54 | V | 'OK' 1009 | CPU2 DIMM | Voltage | 1.54 | V | 'OK' 1076 | +3.3VCC | Voltage | 3.26 | V | 'OK' 1143 | +3.3VSB | Voltage | 3.22 | V | 'OK' 1210 | VBAT | Voltage | 3.19 | V | 'OK' 1277 | CPU1 Temp | OEM Reserved | N/A| N/A | 'OEM Event = h' 1344 | CPU2 Temp | OEM Reserved | N/A| N/A | 'OEM Event = h' 1411 | System Temp | Temperature | 21.00 | C | 'OK' 1478 | P1-DIMM1A | Temperature | 33.00 | C | 'OK' 1545 | P1-DIMM1B | Temperature | 32.00 | C | 'OK' 1612 | P1-DIMM1C | Temperature | N/A| C | N/A 1679 | P1-DIMM2A | Temperature | 36.00 | C | 'OK' 1746 | P1-DIMM2B | Temperature | 34.00 | C | 'OK' 1813 | P1-DIMM2C | Temperature | N/A| C | N/A 1880 | P1-DIMM3A | Temperature | 36.00 | C | 'OK' 1947 | P1-DIMM3B | Temperature | 36.00 | C | 'OK' 2014 | P1-DIMM3C | Temperature | N/A| C | N/A 2081 | P2-DIMM1A | Temperature | 30.00 | C | 'OK' 2148 | P2-DIMM1B | Temperature | 28.00 | C | 'OK' 2215 | P2-DIMM1C | Temperature | N/A| C | N/A 2282 | P2-DIMM2A | Temperature | 27.00 | C | 'OK' 2349 | P2-DIMM2B | Temperature | 27.00 | C | 'OK' 2416 | P2-DIMM2C | Temperature | N/A| C | N/A 2483 | P2-DIMM3A | Temperature | 27.00 | C | 'OK' 2550 | P2-DIMM3B | Temperature | 28.00 | C | 'OK' 2617 | P2-DIMM3C | Temperature | N/A| C | N/A 2684 | Chassis Intru | Physical Security | N/A| N/A | 'OK' 2751 | PS Status | Power Supply | N/A| N/A | 'Presence detected' 'Unrecognized Event = 0100h' 'Unrecognized Event = 0200h' 'Unrecognized Event = 0400h' 'Unrecognized Event = 0800h' 'Unrecognized Event = 1000h' 'Unrecognized Event = 2000h' 'Unrecognized Event = 4000h' Is there any trick that I have just missed to get the config file active? /glz ... the future isMobile Goran Lowkrantz goran.lowkra...@ismobile.com System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ... ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Can't get freeipmi_interpret_sensor.conf to work
Hey Goran, Thanks for the list. I can go ahead and add these motherboards too. I assume they all have the same Supermicro OEM CPU Temp sensors? Do the magnum technologies inc motherboards have a name/product name associated with them? The way I document/organize the code, it would nicer to associated those motherborads w/ Magnum instead of Supermicro. Al On Tue, 2011-09-20 at 08:54 -0700, Goran Lowkrantz wrote: Hi Albert, Works just perfekt. Here is a list of our other Supermicro board: Supermicro X7DB8 10437:4 Supermicro X8DTN 10437:4 Supermicro X8DTL 47488:6 Supermicro X9SCL/X9SCM47488:1572 Supermicro X7SBi-LN4 5593:4404 Supermicro X7SBi-LN4 10437:4 Supermicro X8DTL 5593:6 Supermicro X8DTN+-F 47488:1551 10437: Peppercon AG 47488: Super Micro Computer Inc. 5593: Magnum Technologies Inc. /glz --On September 19, 2011 11:14:48 -0700 Albert Chu ch...@llnl.gov wrote: Hi Goran, Unfortunately that's not how freeipmi_interpret_sensor.conf works. That conf file is for use with the --output-sensor-state option. (In hindsight, I now see the overloading of the word 'interpret' may be confusing). I went ahead and added your motherboard into this beta of FreeIPMI, can you see if it works? You'll still need to specify --interpret-oem-data. You may also want to run --output-sensor-state to see if that brings up an interpretation for those events too. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.7.beta3. tar.gz In addition, you may be interested in the --ignore-unrecognized-events option to eliminate all those unrecognized events. Thanks, Al On Mon, 2011-09-19 at 02:44 -0700, Goran Lowkrantz wrote: I am trying to add the CPU Temp sensors output from our Supermicro servers to freeipmi_interpret_sensor.conf but I can't get it working. As we have quite a few, I would like to get them working so I started with this. The server I am testing on has a X8DTN+-F motherboard, below is the dmidecode output. We are running FreeBSD amd64 8.2-STABLE with FreeIPMI 1.0.6. All files are in the default location /usr/local/etc/freeipmi Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Supermicro Product Name: X8DTN+-F Version: 1234567890 Serial Number: 1234567890 UUID: 25091011-3C00-C25E-8922-003048F7A292 Wake-up Type: Power Switch SKU Number: 1234567890 Family: Server Using bcm-info gives the following output: # bmc-info Device ID : 32 Device Revision : 1 Device SDRs : unsupported Firmware Revision : 2.04 Device Available : yes (normal operation) IPMI Version : 2.0 Sensor Device : supported SDR Repository Device : supported SEL Device: supported FRU Inventory Device : supported IPMB Event Receiver : supported IPMB Event Generator : supported Bridge: unsupported Chassis Device: supported Manufacturer ID : Super Micro Computer Inc. (47488) Product ID: 1551 GUID : ---- Channel Information Channel Number : 0 Medium Type : IPMB (I2C) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 1 Medium Type : 802.3 LAN Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : multi-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 3 Medium Type : Asynch. Serial/Modem (RS-232) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : single-session Vendor ID: Intelligent Platform Management Interface forum (7154) Channel Number : 5 Medium Type : IPMB (I2C) Protocol Type: IPMB-1.0 Active Session Count : 0 Session Support : session-less Vendor ID: Intelligent Platform Management Interface forum (7154) So I would expect the id to be 47488:1551 Verbose output of ipmi-sensors for the two sensors: Record ID: 1277 ID String: CPU1 Temp Sensor Type: OEM Reserved (C0h) Sensor Number: 82 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 1 Entity Instance Type: Physical Entity Event/Reading Type Code: 70h Sensor Event: 'OEM Event = h' Record ID: 1344 ID String: CPU2 Temp Sensor Type: OEM Reserved (C0h) Sensor Number: 81 IPMB Slave Address: 10h Sensor Owner ID: 20h Sensor Owner LUN: 0h Channel Number: 0h Entity ID: system board (7) Entity Instance: 2 Entity Instance Type: Physical Entity Event
Re: [Freeipmi-users] Can't get freeipmi_interpret_sensor.conf to work
| Nominal | -12.10 | V | 'OK' 12 | 5VSB| Voltage | Nominal | 4.92 | V | 'OK' 13 | VBAT| Voltage | Nominal | 3.25 | V | 'OK' 14 | Fan1| Fan | Nominal | 10200.00 | RPM | 'OK' 15 | Fan2| Fan | Nominal | 9500.00| RPM | 'OK' 16 | Fan3| Fan | Critical | 0.00 | RPM | 'At or Below (=) Lower Non-Recoverable Threshold' 17 | Fan4| Fan | Critical | 0.00 | RPM | 'At or Below (=) Lower Non-Recoverable Threshold' 18 | Fan5| Fan | Critical | 0.00 | RPM | 'At or Below (=) Lower Non-Recoverable Threshold' 19 | Fan6/CPU| Fan | Critical | 0.00 | RPM | 'At or Below (=) Lower Non-Recoverable Threshold' 20 | Power Supply| Power Supply | Nominal | N/A| N/A | 'OK' 21 | CPU Internal Er | Module/Board | Critical | N/A| N/A | 'State Asserted' 22 | System Overheat | Module/Board | Nominal | N/A| N/A | 'OK' 23 | Thermal Trip| Module/Board | Nominal | N/A| N/A | 'OK' I have attached screenshots from IPMIView. It seems like that application understands that that some of the fans are not connected as deselecting the 'Hide inactive item' only shows more fans. More interesting is that for the 10437:4 I see nothing of failing event 21 and in the 5593:4404 there is no fail on event 18. /glz --On September 20, 2011 16:40:19 -0700 Albert Chu ch...@llnl.gov wrote: Hi Goran, No problem, I just went ahead and added the support under the Supermicro banner. I've added them to this beta. Could you LMK if it seems to work with all the Supermicro boards you have? http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.7.beta4. tar.gz If you could run w/ --output-sensor-state and see if the event interpretations are working too, I'd appreciate it. Thanks, Al On Tue, 2011-09-20 at 10:34 -0700, Goran Lowkrantz wrote: Hi Albert, Yes, they all have the CPU sensor. Re the Magnum thing, I have no idea why they have different manufacturer code. I looked at the two X8DTL and X7SBi-LN4 boards and could see no visual difference between them. They have different codes in a few places but I don't know if it's date codes or something else. But I am almost 100% sure we got the Magnum systems first, something like 8 to 12 weeks between the two pairs. But then we are in the Swedish north so I have no idea about how long time it takes for Super Micro stock to move this far and thus the delivery times may be irrelevant. /glz --On Tuesday, September 20, 2011 10:04 AM -0700 Albert Chu ch...@llnl.gov wrote: Hey Goran, Thanks for the list. I can go ahead and add these motherboards too. I assume they all have the same Supermicro OEM CPU Temp sensors? Do the magnum technologies inc motherboards have a name/product name associated with them? The way I document/organize the code, it would nicer to associated those motherborads w/ Magnum instead of Supermicro. Al On Tue, 2011-09-20 at 08:54 -0700, Goran Lowkrantz wrote: Hi Albert, Works just perfekt. Here is a list of our other Supermicro board: Supermicro X7DB8 10437:4 Supermicro X8DTN 10437:4 Supermicro X8DTL 47488:6 Supermicro X9SCL/X9SCM 47488:1572 Supermicro X7SBi-LN4 5593:4404 Supermicro X7SBi-LN4 10437:4 Supermicro X8DTL 5593:6 Supermicro X8DTN+-F 47488:1551 10437: Peppercon AG 47488: Super Micro Computer Inc. 5593: Magnum Technologies Inc. /glz --On September 19, 2011 11:14:48 -0700 Albert Chu ch...@llnl.gov wrote: Hi Goran, Unfortunately that's not how freeipmi_interpret_sensor.conf works. That conf file is for use with the --output-sensor-state option. (In hindsight, I now see the overloading of the word 'interpret' may be confusing). I went ahead and added your motherboard into this beta of FreeIPMI, can you see if it works? You'll still need to specify --interpret-oem-data. You may also want to run --output-sensor-state to see if that brings up an interpretation for those events too. http://download.gluster.com/pub/freeipmi/qa-release/freeipmi-1.0.7. bet a3. tar.gz In addition, you may be interested in the --ignore-unrecognized-events option to eliminate all those unrecognized events. Thanks, Al On Mon, 2011-09-19 at 02:44 -0700, Goran Lowkrantz wrote: I am trying to add the CPU Temp sensors output from our Supermicro servers to freeipmi_interpret_sensor.conf but I can't get it working. As we have quite a few, I would like to get them working so I
[Freeipmi-users] FreeIPMI 1.0.8 Released
http://download.gluster.com/pub/freeipmi/1.0.8/ FreeIPMI 1.0.8 - 10/27/11 - o Fix corner case in which invalid SDR entry could be loaded when shared sensors exist on event only records. o Fix several event output corner cases. o Fix 'assumesystemevent' workaround for ipmi-sel. o Fix ipmi-raw and ipmi-oem allocation bug on newer systems, such as RHEL6. o Support Intel Node Manager sensor/SEL events for Intel S2600JF/Appro 512X. o Document workarounds for Intel S2600JF/Appro 512X. o Per definition, output GUID w/ lower case characters in bmc-info. o Other minor bug fixes. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.0.9 Released
http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.0.9.tar.gz FreeIPMI 1.0.9 - 11/21/11 - o Support Supermicro OEM sensors on X9SCA-F-O motherboards. o Support Supermicro OEM sensors on X9SCM-F motherboards with newer firmware. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi-sensors works, ipmimonitoring does not: privilege level cannot be obtained for this user
Hi Phillip, I don't see any debug output, did you forget the attachment? It's possible my servers removed it if you sent it with a .zip attachment. Just send as plain text. On Tue, 2011-11-22 at 08:04 -0800, Phillip Frost wrote: I'm trying to monitor an Apple Xserve. I found the incantation to get ipmi-sensors to work: $ ipmi-sensors -h -u -p -l OPERATOR -W intel20 -D LAN_2_0 I get a long list of sensor data. Groovy. But when I try the same thing with ipmimonitoring I get an error: $ ipmimonitoring -h -u -p -l OPERATOR -W intel20 -D LAN_2_0 ipmi_monitoring_sensor_readings_by_record_id: privilege level cannot be obtained for this user I'm running the tools from debian stable. ipmimonitoring -V tells me ipmimonitoring - 0.7.17.beta2. Attached output from above commands with --debug. As I understand it, this is the host I'm monitoring telling me that I can't get the level OPERATOR for the credentials I have specified. Correct. Yet, I just did it, with ipmi-sensors. Is -l being ignored? Is my understanding incorrect? What's wrong? Most likely there was an issue in the libipmimonitoring code path. The intel20 workaround is particularly sensitive. This is a pretty ancient version of FreeIPMI. Any chance you could try with a newer version (I just released 1.0.9) and send me the --debug output? Al ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi support with HP iLO2 servers initial success!
Hi John, The short answer is there are a number of bugs in the HP iLO firmware. But some combination of options and/or workaround flags will get around them and allow you to use FreeIPMI w/ HP iLO. (Assuming no firmware fixes have occurred since this thread.) See the manpage for a list of workarounds. My recollection is a lot of HP iLO machines do not support IPMI 1.5, only IPMI 2.0, so you'll have to use -D=LAN_2_0 to use IPMI 2.0. Al On Wed, 2011-12-07 at 01:36 -0800, john s. wrote: Hello Everybody Sorry for digging out this thread but i can't find no other (newer) post which is similar to this one ... 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. command : ipmipower -h cut0iogw1-ilo -D LAN_2_0 -s so is it still a bug or is it the normal behaviour on hp ilo connects? best regards john s. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Dell ipmi-oem chassis slot availability?
Hi Chris, I might be misunderstanding your question, but it seems you want to figure out what type of board is inside each slot? I assume the ipmi-oem Dell command 'get-system-info' isn't enough b/c you only get the board name and not the slot number? I don't know of any OEM commands for this, so the first thing is I'd bug Dell, b/c someone there might be able to provide it (you will have to fight them to get to the right people, the first line support will likely have no idea). If you get something from them, please let the list know and we can put it in ipmi-oem. Depending on your willingness to try and reverse engineer something, there might be a way to determine it. The following is an ipmi-raw that should implement the same thing as ipmi-oem dell get-system-info asset-tag /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0 In ipmi-oem here's a comment on the parameter numbers: * guid parameter = 0xC3 * asset-tag parameter = 0xC4 * service-tag parameter = 0xC5 * chassis-service-tag parameter = 0xC6 * chassis-related-service-tag parameter = 0xC7 * board-revision parameter = 0xC8 This is what we know of or have been told. It wouldn't be hard to imagine that 0xC9, 0xCA ,0xCB might return your slot number. Al On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote: I've just learned about the wonders of IPMI this past month and have re-written our inventory system from scratch to take advantage of the data the FreeIPMI suite of tools provides easy access to. Right now the only drawback is that I have to run a secondary script at each co-location to access each of our Dell M1000e chassis, running proprietary racadm command over SSH to correlate which 10g/11g PowerEdge blades are running in the various slots. I've been digging through the documentation in hopes of finding either a oem command that I can run or even a ipmi-raw command that can be passed to each blade to pull this data, but so far I've come up short. Has anyone on this list been able to identify a method to capture this particular information? Dell's OMSA utility also provides the slot information as seen in the output below. # omreport chassis info Chassis Information Index: 0 Chassis Name : Main System Chassis Host Name: iDRAC6 Version : 1.60 Chassis Model: PowerEdge M600 Chassis Lock : Not Present Chassis Service Tag : XX11YY2 Server Module Service Tag: YY11XX2 Server Module Location : Slot 14 -- This is what I need Flash chassis identify LED state : Off Flash chassis identify LED timeout value : 300 Thanks in advance for the time guys. --Chris ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] DELL C6100 Megarac - ipmi_ctx_open_outofband
... ] = challenge_string[16B] ip-address: [ 1Bh E8h E7h 8Dh 76h 5Ah 2Eh 63h ] ip-address: [ 33h 9Fh C9h 9Ah 66h 32h 0Dh B7h ] ip-address: IPMI Trailer: ip-address: -- ip-address: [ 19h] = checksum2[ 8b] ip-address: = ip-address: IPMI 1.5 Activiate Session Request ip-address: = ip-address: RMCP Header: ip-address: ip-address: [ 6h] = version[ 8b] ip-address: [ 0h] = reserved[ 8b] ip-address: [ FFh] = sequence_number[ 8b] ip-address: [ 7h] = message_class.class[ 5b] ip-address: [ 0h] = message_class.reserved[ 2b] ip-address: [ 0h] = message_class.ack[ 1b] ip-address: IPMI Session Header: ip-address: ip-address: [ 2h] = authentication_type[ 8b] ip-address: [ 0h] = session_sequence_number[32b] ip-address: [4DF527F8h] = session_id[32b] ip-address: [ BYTE ARRAY ... ] = authentication_code[16B] ip-address: [ 1Eh FCh 53h 98h 70h 2Eh 25h 99h ] ip-address: [ 6Eh EBh 3Eh FFh ADh 95h E6h 66h ] ip-address: [ 1Dh] = ipmi_msg_len[ 8b] ip-address: IPMI Message Header: ip-address: ip-address: [ 20h] = rs_addr[ 8b] ip-address: [ 0h] = rs_lun[ 2b] ip-address: [ 6h] = net_fn[ 6b] ip-address: [ C8h] = checksum1[ 8b] ip-address: [ 81h] = rq_addr[ 8b] ip-address: [ 0h] = rq_lun[ 2b] ip-address: [ 32h] = rq_seq[ 6b] ip-address: IPMI Command Data: ip-address: -- ip-address: [ 3Ah] = cmd[ 8b] ip-address: [ 2h] = authentication_type[ 4b] ip-address: [ 0h] = reserved1[ 4b] ip-address: [ 3h] = maximum_privilege_level[ 4b] ip-address: [ 0h] = reserved2[ 4b] ip-address: [ BYTE ARRAY ... ] = challenge_string[16B] ip-address: [ 1Bh E8h E7h 8Dh 76h 5Ah 2Eh 63h ] ip-address: [ 33h 9Fh C9h 9Ah 66h 32h 0Dh B7h ] ip-address: [ 6A5AC49h] = initial_outbound_sequence_number[32b] ip-address: IPMI Trailer: ip-address: -- ip-address: [ 6Fh] = checksum2[ 8b] ip-address: = ip-address: IPMI 1.5 Activiate Session Response ip-address: = ip-address: RMCP Header: ip-address: ip-address: [ 6h] = version[ 8b] ip-address: [ 0h] = reserved[ 8b] ip-address: [ FFh] = sequence_number[ 8b] ip-address: [ 7h] = message_class.class[ 5b] ip-address: [ 0h] = message_class.reserved[ 2b] ip-address: [ 0h] = message_class.ack[ 1b] ip-address: IPMI Session Header: ip-address: ip-address: [ 2h] = authentication_type[ 8b] ip-address: [ 0h] = session_sequence_number[32b] ip-address: [4DF527F8h] = session_id[32b] ip-address: [ BYTE ARRAY ... ] = authentication_code[16B] ip-address: [ 51h C6h 11h 08h 55h 50h B1h 12h ] ip-address: [ C2h 42h 9Eh 06h 9Dh 9Ch ADh 61h ] ip-address: [ 8h] = ipmi_msg_len[ 8b] ip-address: IPMI Message Header: ip-address: ip-address: [ 81h] = rq_addr[ 8b] ip-address: [ 0h] = rq_lun[ 2b] ip-address: [ 7h] = net_fn[ 6b] ip-address: [ 63h] = checksum1[ 8b] ip-address: [ 20h] = rs_addr[ 8b] ip-address: [ 0h] = rs_lun[ 2b] ip-address: [ 32h] = rq_seq[ 6b] ip-address: IPMI Command Data: ip-address: -- ip-address: [ 3Ah] = cmd[ 8b] ip-address: [ CCh] = comp_code[ 8b] ip-address: IPMI Trailer: ip-address: -- ip-address: [ 12h] = checksum2[ 8b] ipmi_ctx_open_outofband: bad completion code: request data/parameter invalid I tried different workaround settings or authorization methods but can't get any working config. Web-access of these IPMI interfaces works as expected. Thanks for any advice on this problem. Alex -- Alexander Warschun Systemadministration -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Dell ipmi-oem chassis slot availability?
On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote: Al, I tried iterating from 0xC0 through 0xCF on some Dell M610s and didn't find the slot number. I compared the results of several that were in the same chassis so that most of the information would be the same. I saw no differences that seemed to indicate the slot number. The only differences at all that I saw from blades in the same chassis were at 0xC3 and 0xC5 (expected). We don't have asset tags set or I would expect to see differences in 0xC4. Sorry it didn't work. It was worth a shot :-) Al Ryan On 12/19/2011 11:04 AM, Albert Chu wrote: Hi Chris, I might be misunderstanding your question, but it seems you want to figure out what type of board is inside each slot? I assume the ipmi-oem Dell command 'get-system-info' isn't enough b/c you only get the board name and not the slot number? I don't know of any OEM commands for this, so the first thing is I'd bug Dell, b/c someone there might be able to provide it (you will have to fight them to get to the right people, the first line support will likely have no idea). If you get something from them, please let the list know and we can put it in ipmi-oem. Depending on your willingness to try and reverse engineer something, there might be a way to determine it. The following is an ipmi-raw that should implement the same thing as ipmi-oem dell get-system-info asset-tag /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0 In ipmi-oem here's a comment on the parameter numbers: * guid parameter = 0xC3 * asset-tag parameter = 0xC4 * service-tag parameter = 0xC5 * chassis-service-tag parameter = 0xC6 * chassis-related-service-tag parameter = 0xC7 * board-revision parameter = 0xC8 This is what we know of or have been told. It wouldn't be hard to imagine that 0xC9, 0xCA ,0xCB might return your slot number. Al On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote: I've just learned about the wonders of IPMI this past month and have re-written our inventory system from scratch to take advantage of the data the FreeIPMI suite of tools provides easy access to. Right now the only drawback is that I have to run a secondary script at each co-location to access each of our Dell M1000e chassis, running proprietary racadm command over SSH to correlate which 10g/11g PowerEdge blades are running in the various slots. I've been digging through the documentation in hopes of finding either a oem command that I can run or even a ipmi-raw command that can be passed to each blade to pull this data, but so far I've come up short. Has anyone on this list been able to identify a method to capture this particular information? Dell's OMSA utility also provides the slot information as seen in the output below. # omreport chassis info Chassis Information Index: 0 Chassis Name : Main System Chassis Host Name: iDRAC6 Version : 1.60 Chassis Model: PowerEdge M600 Chassis Lock : Not Present Chassis Service Tag : XX11YY2 Server Module Service Tag: YY11XX2 Server Module Location : Slot 14-- This is what I need Flash chassis identify LED state : Off Flash chassis identify LED timeout value : 300 Thanks in advance for the time guys. --Chris ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
[moving thread to freeipmi-devel] Hey Ryan, This looks very interesting. 0xDC isn't one I know of yet. It could totally be available and just not published by Dell yet. rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 the 0x59 is the command byte (same as in the input command line). The next 0x00 is the completion code (0 = success). In similar formats from Dell (see ipmi-oem-dell.c), the byte afterwards is typically a length/count of some sort, 0x11 = 17, which does equal the remaining number of bytes. So we're on the right track. I took a guess that this might be ascii, lookie at what it maps too. 53 = S 4C = L 4F = O 54 = T 2D = - 31 = 1 36 = 6 only the 0x10 = DLE is an oddity. Do 0xD1 - 0xDF output anything similar? I'm wondering if this data is a part of additional data. Could you also fiddle with: /usr/sbin/ipmi-raw 0 6 59 0 0xDC XX YY the XX YY bytes. They are the set selector/block selector fields. Perhaps there is additional string data surrounding this. If it's consistent across all slots, systems, and we can figure this all out, we can get this into ipmi-oem. Chris can you also verify on your systems? Al On Tue, 2011-12-20 at 12:43 -0800, Ryan Cox wrote: Al, I just found this on 0xDC for a blade in slot 16: # ipmi-raw 0 6 59 0 0xDC 0 0 rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 You'll have to bear with me on this since I'm not sure of what the standard is for counting bytes when referring to the data returned from ipmi-raw, so I'll assume the 59 is byte 0. Bytes 11 and 12 (31 and 36 above) have the slot number for each of the M610s, M910s, M600s, and M610X that I tested. It's a weird way of encoding it but it has worked everywhere I have tested. Bit 0 of byte 11 is the first *decimal* digit of the slot number (i.e. 0 or 1). I assume that other bits could be used if Dell comes out with a chassis that holds more blades but, of course, have no way to test that. Bits 0-3 of byte 12 are the second decimal digit of the slot number (i.e. 0-9). I've tested on close to 100 blades and it is consistent. Examples: Slot 15: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 35 00 00 00 00 00 00 00 Slot 05: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 35 00 00 00 00 00 00 00 Slot 02: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 32 00 00 00 00 00 00 00 Slot 14: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 34 00 00 00 00 00 00 00 Ryan On 12/20/2011 12:50 PM, Albert Chu wrote: On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote: Al, I tried iterating from 0xC0 through 0xCF on some Dell M610s and didn't find the slot number. I compared the results of several that were in the same chassis so that most of the information would be the same. I saw no differences that seemed to indicate the slot number. The only differences at all that I saw from blades in the same chassis were at 0xC3 and 0xC5 (expected). We don't have asset tags set or I would expect to see differences in 0xC4. Sorry it didn't work. It was worth a shot :-) Al Ryan On 12/19/2011 11:04 AM, Albert Chu wrote: Hi Chris, I might be misunderstanding your question, but it seems you want to figure out what type of board is inside each slot? I assume the ipmi-oem Dell command 'get-system-info' isn't enough b/c you only get the board name and not the slot number? I don't know of any OEM commands for this, so the first thing is I'd bug Dell, b/c someone there might be able to provide it (you will have to fight them to get to the right people, the first line support will likely have no idea). If you get something from them, please let the list know and we can put it in ipmi-oem. Depending on your willingness to try and reverse engineer something, there might be a way to determine it. The following is an ipmi-raw that should implement the same thing as ipmi-oem dell get-system-info asset-tag /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0 In ipmi-oem here's a comment on the parameter numbers: * guid parameter = 0xC3 * asset-tag parameter = 0xC4 * service-tag parameter = 0xC5 * chassis-service-tag parameter = 0xC6 * chassis-related-service-tag parameter = 0xC7 * board-revision parameter = 0xC8 This is what we know of or have been told. It wouldn't be hard to imagine that 0xC9, 0xCA ,0xCB might return your slot number. Al On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote: I've just learned about the wonders of IPMI this past month and have re-written our inventory system from scratch to take advantage of the data the FreeIPMI suite of tools provides easy access to. Right now the only drawback is that I have to run a secondary script at each co-location to access each of our Dell M1000e chassis, running proprietary racadm command over SSH to correlate which 10g/11g PowerEdge blades are running in the various slots
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
One extra thing I just thought of. The data that Dell typically pulls asset-tag, board-revision, etc. is actually stored in the same place as the FRU. Did you guys check the FRU via ipmi-fru? Perhaps with ipmi-fru -vv? Is it possible the slot data is hidden in there somewhere? Al On Tue, 2011-12-20 at 13:47 -0800, Albert Chu wrote: [moving thread to freeipmi-devel] Hey Ryan, This looks very interesting. 0xDC isn't one I know of yet. It could totally be available and just not published by Dell yet. rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 the 0x59 is the command byte (same as in the input command line). The next 0x00 is the completion code (0 = success). In similar formats from Dell (see ipmi-oem-dell.c), the byte afterwards is typically a length/count of some sort, 0x11 = 17, which does equal the remaining number of bytes. So we're on the right track. I took a guess that this might be ascii, lookie at what it maps too. 53 = S 4C = L 4F = O 54 = T 2D = - 31 = 1 36 = 6 only the 0x10 = DLE is an oddity. Do 0xD1 - 0xDF output anything similar? I'm wondering if this data is a part of additional data. Could you also fiddle with: /usr/sbin/ipmi-raw 0 6 59 0 0xDC XX YY the XX YY bytes. They are the set selector/block selector fields. Perhaps there is additional string data surrounding this. If it's consistent across all slots, systems, and we can figure this all out, we can get this into ipmi-oem. Chris can you also verify on your systems? Al On Tue, 2011-12-20 at 12:43 -0800, Ryan Cox wrote: Al, I just found this on 0xDC for a blade in slot 16: # ipmi-raw 0 6 59 0 0xDC 0 0 rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 You'll have to bear with me on this since I'm not sure of what the standard is for counting bytes when referring to the data returned from ipmi-raw, so I'll assume the 59 is byte 0. Bytes 11 and 12 (31 and 36 above) have the slot number for each of the M610s, M910s, M600s, and M610X that I tested. It's a weird way of encoding it but it has worked everywhere I have tested. Bit 0 of byte 11 is the first *decimal* digit of the slot number (i.e. 0 or 1). I assume that other bits could be used if Dell comes out with a chassis that holds more blades but, of course, have no way to test that. Bits 0-3 of byte 12 are the second decimal digit of the slot number (i.e. 0-9). I've tested on close to 100 blades and it is consistent. Examples: Slot 15: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 35 00 00 00 00 00 00 00 Slot 05: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 35 00 00 00 00 00 00 00 Slot 02: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 32 00 00 00 00 00 00 00 Slot 14: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 34 00 00 00 00 00 00 00 Ryan On 12/20/2011 12:50 PM, Albert Chu wrote: On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote: Al, I tried iterating from 0xC0 through 0xCF on some Dell M610s and didn't find the slot number. I compared the results of several that were in the same chassis so that most of the information would be the same. I saw no differences that seemed to indicate the slot number. The only differences at all that I saw from blades in the same chassis were at 0xC3 and 0xC5 (expected). We don't have asset tags set or I would expect to see differences in 0xC4. Sorry it didn't work. It was worth a shot :-) Al Ryan On 12/19/2011 11:04 AM, Albert Chu wrote: Hi Chris, I might be misunderstanding your question, but it seems you want to figure out what type of board is inside each slot? I assume the ipmi-oem Dell command 'get-system-info' isn't enough b/c you only get the board name and not the slot number? I don't know of any OEM commands for this, so the first thing is I'd bug Dell, b/c someone there might be able to provide it (you will have to fight them to get to the right people, the first line support will likely have no idea). If you get something from them, please let the list know and we can put it in ipmi-oem. Depending on your willingness to try and reverse engineer something, there might be a way to determine it. The following is an ipmi-raw that should implement the same thing as ipmi-oem dell get-system-info asset-tag /usr/sbin/ipmi-raw 0 6 59 0 0xC4 0 0 In ipmi-oem here's a comment on the parameter numbers: * guid parameter = 0xC3 * asset-tag parameter = 0xC4 * service-tag parameter = 0xC5 * chassis-service-tag parameter = 0xC6 * chassis-related-service-tag parameter = 0xC7 * board-revision parameter = 0xC8 This is what we know of or have been told. It wouldn't be hard to imagine that 0xC9, 0xCA ,0xCB might return your slot number. Al On Sun, 2011-12-18 at 06:39 -0800, DeRamus, Chris wrote: I've
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
it is) and 0xDE only, though the R710's iDRAC firmware is much older. The R710 returns zero bytes for most of the others but doesn't error out. Cool. 0xD1 is already done in ipmi-oem as well as 0xDA (MAC address). Going through and re-learning this code in ipmi-oem, it seems a number of these map to this format: * Parameter data response formatted: * * Set Selector 0: * * 1st byte = set selector * 2nd byte = encoding * 3rd byte = string length * ? bytes = string * * Set Selector 0 * * 1st byte = set selector * ? bytes = string I'm in the middle of something right now, but I'll try to get this into ipmi-oem sometime soon and send you link to a code tree w/ beta code. I'll probably need your guy's help to write the manpage entries and such since you guys know the hardware better :-) Al P.S. the FreeIPMI 1.1.1 beta is about to come out, so I doubt it'll get into that. 1.1.2 is a more likely target. Multiple set selectors (correct term?) are required for at least 0xDD and 0xDE. The block selector seemed to do nothing. Ryan On 12/20/2011 02:47 PM, Albert Chu wrote: [moving thread to freeipmi-devel] Hey Ryan, This looks very interesting. 0xDC isn't one I know of yet. It could totally be available and just not published by Dell yet. rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 the 0x59 is the command byte (same as in the input command line). The next 0x00 is the completion code (0 = success). In similar formats from Dell (see ipmi-oem-dell.c), the byte afterwards is typically a length/count of some sort, 0x11 = 17, which does equal the remaining number of bytes. So we're on the right track. I took a guess that this might be ascii, lookie at what it maps too. 53 = S 4C = L 4F = O 54 = T 2D = - 31 = 1 36 = 6 only the 0x10 = DLE is an oddity. Do 0xD1 - 0xDF output anything similar? I'm wondering if this data is a part of additional data. Could you also fiddle with: /usr/sbin/ipmi-raw 0 6 59 0 0xDC XX YY the XX YY bytes. They are the set selector/block selector fields. Perhaps there is additional string data surrounding this. If it's consistent across all slots, systems, and we can figure this all out, we can get this into ipmi-oem. Chris can you also verify on your systems? Al On Tue, 2011-12-20 at 12:43 -0800, Ryan Cox wrote: Al, I just found this on 0xDC for a blade in slot 16: # ipmi-raw 0 6 59 0 0xDC 0 0 rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 36 00 00 00 00 00 00 00 You'll have to bear with me on this since I'm not sure of what the standard is for counting bytes when referring to the data returned from ipmi-raw, so I'll assume the 59 is byte 0. Bytes 11 and 12 (31 and 36 above) have the slot number for each of the M610s, M910s, M600s, and M610X that I tested. It's a weird way of encoding it but it has worked everywhere I have tested. Bit 0 of byte 11 is the first *decimal* digit of the slot number (i.e. 0 or 1). I assume that other bits could be used if Dell comes out with a chassis that holds more blades but, of course, have no way to test that. Bits 0-3 of byte 12 are the second decimal digit of the slot number (i.e. 0-9). I've tested on close to 100 blades and it is consistent. Examples: Slot 15: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 35 00 00 00 00 00 00 00 Slot 05: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 35 00 00 00 00 00 00 00 Slot 02: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 32 00 00 00 00 00 00 00 Slot 14: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 31 34 00 00 00 00 00 00 00 Ryan On 12/20/2011 12:50 PM, Albert Chu wrote: On Tue, 2011-12-20 at 11:20 -0800, Ryan Cox wrote: Al, I tried iterating from 0xC0 through 0xCF on some Dell M610s and didn't find the slot number. I compared the results of several that were in the same chassis so that most of the information would be the same. I saw no differences that seemed to indicate the slot number. The only differences at all that I saw from blades in the same chassis were at 0xC3 and 0xC5 (expected). We don't have asset tags set or I would expect to see differences in 0xC4. Sorry it didn't work. It was worth a shot :-) Al Ryan On 12/19/2011 11:04 AM, Albert Chu wrote: Hi Chris, I might be misunderstanding your question, but it seems you want to figure out what type of board is inside each slot? I assume the ipmi-oem Dell command 'get-system-info' isn't enough b/c you only get the board name and not the slot number? I don't know of any OEM commands for this, so the first thing is I'd bug Dell, b/c someone there might be able to provide it (you will have to fight them to get to the right people, the first line support will likely have no idea). If you get something from them, please let the list know and we can put it in ipmi-oem. Depending on your willingness to try
[Freeipmi-users] FreeIPMI 1.1.1.Beta0 Released
Hi everyone, FreeIPMI 1.1.1 Beta0 has been released. http://alpha.gnu.org/gnu/freeipmi/freeipmi-1.1.1.beta0.tar.gz As always, I'd appreciate any testing people can provide, even just sanity does it basically compile and still execute testing is always appreciated. There weren't any major architectural changes, so I don't anticipate too many problems. However, there was a significant amount of portability cleanup, as well as a huge overhaul in the build system and code organization. I fear possible build/compile breaks on some non-mainstream Linux systems. Thanks, Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
for an M600 and may be a more portable option:
0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0E 00 00 22 19 7B =
{
0xD4 13 0: rcvd: 59 00 11 25 93 1E 00 00 22 19 7B 25 94 0E 01 = % �
{ % �
0xD4 14 0: rcvd: 59 00 11 00 22 19 7B 25 95 1E 01 00 22 19 7B =
{ % � {
0xD4 15 0: rcvd: 59 00 11 25 96 16 00 00 00 00 00 00 00 16 00 = % �
0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 16 00 00 00 00 00 =
0xD4 17 0: rcvd: 59 00 11 00 00 16 00 00 00 00 00 00 00 1F 00 =
Server-15 Present 00:22:19:7B:2C:58 00:22:19:7B:25:93
00:22:19:7B:25:95
I'm going to be out of the office for the holidays starting now, so I
may or may not be able to respond to any emails for a while. I also
need to investigate higher numbered set selectors more. I'm getting
results for some up to 0x30 that I spot checked.
Ryan
On 12/20/2011 04:18 PM, Albert Chu wrote:
Hey Ryan,
On Tue, 2011-12-20 at 14:34 -0800, Ryan Cox wrote:
Al,
I should have caught that it was ASCII :)
Please pardon the horrific line noise Here's the output for an M610
using a very ugly command I strung together:
# for a in {0..9} A B C D E F; do for selector in {0..15}; do for
blocksel in {0..15}; do echo -ne \n0xD$a $selector $blocksel: ;
ipmi-raw 0 6 59 0 0xD$a $selector $blocksel | perl -e '$s =; chomp
$s; print $s = \; @bytes = split /\s+/, $s; @bytes; if($bytes[2] ne
00) { print Error code $bytes[2] returned\n; exit; } for($a=4;
$a$#bytes+1; $a++) { printf %s , chr(hex($bytes[$a])); } print
\\n;'; done; done; done |grep -v Error |grep -a rcvd
0xD1 0 0: rcvd: 59 00 11 00 00 0F 50 6F 77 65 72 45 64 67 65 20 4D 36 31
30 = P o w e r E d g e M 6 1 0
0xD1 1 0: rcvd: 59 00 11 01 00 =
0xD1 2 0: rcvd: 59 00 11 02 =
0xD1 3 0: rcvd: 59 00 11 03 =
0xD2 0 0: rcvd: 59 00 11 01 =
0xD3 0 0: rcvd: 59 00 11 00 00 =
0xD4 1 0: rcvd: 59 00 11 02 01 C2 06 02 00 50 5F 53 31 00 00 =
� P _ S 1
0xD4 2 0: rcvd: 59 00 11 02 02 C2 06 02 00 50 5F 53 31 00 00 =
� P _ S 1
0xD4 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 5 0: rcvd: 59 00 11 01 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 05 00 00 26 B9 FC = �
�
0xD4 13 0: rcvd: 59 00 11 B2 7C 15 00 00 26 B9 FC B2 7D 05 01 = � |
� � � }
0xD4 14 0: rcvd: 59 00 11 00 26 B9 FC B2 7E 15 01 00 26 B9 FC =� �
� ~ � �
0: rcvd: 59 00 11 B2 7F 0D 00 00 00 00 00 00 00 0D 00 = �
0xD5 1 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 2 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 5 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD6 0 0: rcvd: 59 00 11 00 01 0F 00 =
0xDC 0 0: rcvd: 59 00 11 00 00 10 53 4C 4F 54 2D 30 36 00 00 00 00 00 00
00 = S L O T - 0 6
0xDC 1 0: rcvd: 59 00 11 01 00 00 =
0xDC 2 0: rcvd: 59 00 11 02 =
0xDC 3 0: rcvd: 59 00 11 03 =
0xDD 0 0: rcvd: 59 00 11 00 00 27 00 01 C0 A8 D2 8A 00 00 00 00 00 00 00
00 = ' � � � �
0xDD 1 0: rcvd: 59 00 11 01 00 00 00 00 33 2E 30 35 20 28 42 75 69 6C 64
20 = 3 . 0 5 ( B u i l d
0xDD 2 0: rcvd: 59 00 11 02 31 29 00 00 00 00 00 00 0B = 1 )
0xDD 3 0: rcvd: 59 00 11 03 00 00 00 00 D8 3A 8D BE D7 39 8D BE 00 00 00
00 = � : � � � 9 � �
0xDD 4 0: rcvd: 59 00 11 04 02 00 00 00 24 7A 2A 40 DC 72 02 00 01 00 00
00 = $ z * @ � r
0xDE 0 0: rcvd: 59 00 11 00 00 1B 68 74 74 70 73 3A 2F 2F 31 39 32 2E 31
36 = h t t p s : / / 1 9 2 . 1 6
0xDE 1 0: rcvd: 59 00 11 01 38 2E 32 31 30 2E 31 33 38 3A 34 34 33 =
8 . 2 1 0 . 1 3 8 : 4 4 3
0xDE 2 0: rcvd: 59 00 11 02 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
Hey Ryan,
H. You're pretty deep into the set selectors by that point. I'm
wondering if you may have wandered into a region of data that we
normally shouldn't wander into (i.e. the IPMI get system info command
may just be reading memory at whatever pointer it is told). In this
particular case, there's a lot of the 0xD4 data earlier on that we're
still not clear about what it is.
Al
On Tue, Dec 20, 2011 at 4:00 PM, Ryan Cox ryan_...@byu.edu wrote:
Al,
Sounds good. Just so you know, 0xDA and ipmi-oem dell get-system-info
mac-addresses don't return anything useful for 11G systems. The ipmi-oem
command does work on an M600 (which it gets from 0xCB based on my reading of
the source code).
The MAC address for an M610 is actually at 0xD4:
0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0F 00 00 23 AE FC =
# � �
0xD4 13 0: rcvd: 59 00 11 E6 D4 1F 00 00 23 AE FC E6 D5 0F 01 = � � #
� � � �
0xD4 14 0: rcvd: 59 00 11 00 23 AE FC E6 D6 1F 01 00 23 AE FC = # � � �
� # � �
0xD4 15 0: rcvd: 59 00 11 E6 D7 17 00 00 00 00 00 00 00 17 00 = � �
0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 17 00 00 00 00 00 =
0xD4 17 0: rcvd: 59 00 11 00 00 17 00 00 00 00 00 00 00 17 00 =
Name Presence BMC MAC Address NIC1 MAC Address NIC2 MAC Address
Server-16 Present 00:23:AE:FB:8D:FF 00:23:AE:FC:E6:D4
00:23:AE:FC:E6:D6
It appears consistent for an M600 and may be a more portable option:
0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 0E 00 00 22 19 7B =
{
0xD4 13 0: rcvd: 59 00 11 25 93 1E 00 00 22 19 7B 25 94 0E 01 = % �
{ % �
0xD4 14 0: rcvd: 59 00 11 00 22 19 7B 25 95 1E 01 00 22 19 7B = { %
� {
0xD4 15 0: rcvd: 59 00 11 25 96 16 00 00 00 00 00 00 00 16 00 = % �
0xD4 16 0: rcvd: 59 00 11 00 00 00 00 00 00 16 00 00 00 00 00 =
0xD4 17 0: rcvd: 59 00 11 00 00 16 00 00 00 00 00 00 00 1F 00 =
Server-15 Present 00:22:19:7B:2C:58 00:22:19:7B:25:93
00:22:19:7B:25:95
I'm going to be out of the office for the holidays starting now, so I may or
may not be able to respond to any emails for a while. I also need to
investigate higher numbered set selectors more. I'm getting results for
some up to 0x30 that I spot checked.
Ryan
On 12/20/2011 04:18 PM, Albert Chu wrote:
Hey Ryan,
On Tue, 2011-12-20 at 14:34 -0800, Ryan Cox wrote:
Al,
I should have caught that it was ASCII :)
Please pardon the horrific line noise Here's the output for an M610
using a very ugly command I strung together:
# for a in {0..9} A B C D E F; do for selector in {0..15}; do for
blocksel in {0..15}; do echo -ne \n0xD$a $selector $blocksel: ;
ipmi-raw 0 6 59 0 0xD$a $selector $blocksel | perl -e '$s =; chomp
$s; print $s = \; @bytes = split /\s+/, $s; @bytes; if($bytes[2] ne
00) { print Error code $bytes[2] returned\n; exit; } for($a=4;
$a$#bytes+1; $a++) { printf %s , chr(hex($bytes[$a])); } print
\\n;'; done; done; done |grep -v Error |grep -a rcvd
0xD1 0 0: rcvd: 59 00 11 00 00 0F 50 6F 77 65 72 45 64 67 65 20 4D 36 31
30 = P o w e r E d g e M 6 1 0
0xD1 1 0: rcvd: 59 00 11 01 00 =
0xD1 2 0: rcvd: 59 00 11 02 =
0xD1 3 0: rcvd: 59 00 11 03 =
0xD2 0 0: rcvd: 59 00 11 01 =
0xD3 0 0: rcvd: 59 00 11 00 00 =
0xD4 1 0: rcvd: 59 00 11 02 01 C2 06 02 00 50 5F 53 31 00 00 = �
P _ S 1
0xD4 2 0: rcvd: 59 00 11 02 02 C2 06 02 00 50 5F 53 31 00 00 = �
P _ S 1
0xD4 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 4 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 5 0: rcvd: 59 00 11 01 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 6 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 7 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 8 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 9 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 10 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 11 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 =
0xD4 12 0: rcvd: 59 00 11 00 00 00 00 00 1F 05 00 00 26 B9 FC = �
�
0xD4 13 0: rcvd: 59 00 11 B2 7C 15 00 00 26 B9 FC B2 7D 05 01 = � |
� � � }
0xD4 14 0: rcvd: 59 00 11 00 26 B9 FC B2 7E 15 01 00 26 B9 FC = � �
� ~ � �
0: rcvd: 59 00 11 B2 7F 0D 00 00 00 00 00 00 00 0D 00 = � 0xD5 1 0:
rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 2 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 3 0: rcvd: 59 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=
0xD5 4 0: rcvd: 59 00 11 00 00 00 00 00
Re: [Freeipmi-users] [Freeipmi-devel] Dell ipmi-oem chassis slot availability?
Hey Ryan, Chris, At this branch I added new Dell additions to ipmi-oem. If you could try them out, I'd appreciate it. The branch for this new code is at: svn co http://svn.savannah.gnu.org/svn/freeipmi/branches/ipmioemdellgetsysteminfo after checking out: ./autogen.sh ; ./configure --enable-debug ; make and then ipmi-oem/ipmi-oem dell get-system-info X (of course run w/ outofband options as needed.) the new options are Option: slot-number (0xDC) Option: system-revision (0xF4) Option: idrac-info (0xDD) Option: idrac-ipv4-url (0xDE) Option: idrac-gui-webserver-control (0xE1) Option: cmc-ipv4-url (0xE0) Option: cmc-ipv6-info (0xF2) Option: cmc-ipv6-url (0xF3) Option: snmp-ipv6-info (0xF0) I also added 12G mac address support w/ mac-addresses. Unsure if that will fix your earlier described problem. I found a Poweredge R610 and could verify idrac-info, idrac-ipv4-url, idrac-gui-webserver-control. None of the rest have been verified to work. There might be others we can add to this list once we learn more. We'll need to iterate a tad to figure it all out. Please let me know if you find any issues. Al On Thu, 2011-12-22 at 15:23 -0800, Albert Chu wrote: Hi Ryan, I totally forgot: #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_STRING 0xC1 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_CONFIGURATION 0xC2 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_GUID 0xC3 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_ASSET_TAG 0xC4 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_SERVICE_TAG 0xC5 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CHASSIS_SERVICE_TAG 0xC6 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CHASSIS_RELATED_SERVICE_TAG 0xC7 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_BOARD_REVISION 0xC8 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_ID 0xC9 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_BIOS_FEATURE 0xCA /* Only for 10G systems */ #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_NICS_MAC_ADDRESSES 0xCB #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_NICS_CAPABILITY 0xCE #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_PLATFORM_MODEL_NAME 0xD1 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LOCAL_CONSOLE_LOCKOUT 0xD6 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_POWER_STAGGERING_AC_RECOVERY 0xD8 /* achu: this one is taken from code, is correct name? */ #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_11G_MAC_ADDRESSES 0xDA #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IDRAC_INFO 0xDD #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IDRAC_IPV4_URL 0xDE #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMD_IPV4_URL 0xE0 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_GUI_WEBSERVER_CONTROL 0xE1 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_PLATFORM_SPECIFIC_DEVICE_INFORMATION 0xE3 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_LCD_STATUS 0xE7 /* achu: this one is taken from code, is correct name? */ #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_POWER_CAPACITY 0xEA #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_AVERAGE_POWER_CONSUMPTION_STATISTICS 0xEB #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_MAX_POWER_CONSUMPTION_STATISTICS 0xEC #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_MIN_POWER_CONSUMPTION_STATISTICS 0xED #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_EMBEDDED_VIDEO_STATUS 0xEE #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_ISCSI_NICS_MAC_ADDRESSES 0xEF #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_IPV6_SNMP_TRAP_DESTINATION_ADDRESS 0xF0 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_INTERNAL_STORAGE_SLOT_INFO 0xF1 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMC_IPV6_INFO 0xF2 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_CMC_IPV6_URL 0xF3 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_SYSTEM_REVISION 0xF4 #define IPMI_SYSTEM_INFO_PARAMETER_OEM_DELL_REDUNDANCY_POLICY 0xFE Some are implemented/hidden within other ipmi-oem Dell command's b/c the output format is unique/different (most notably the power consumption stuff). However, many were not implemented for simple reason that I did not have access to a motherboard that supported them or I found the info not useful. I'll start adding a few I wasn't interested in before (like idrac info) and a few of those we discussed earlier. Play around with the other ones and LMK what works for you. I can add them and we can iterate as I add them to ipmi-oem. Note that many don't output in ASCII, we're mostly just
[Freeipmi-users] FreeIPMI 1.1.1 Released
http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.1.1.tar.gz FreeIPMI 1.1.1 - 01/03/11 - Tools - o Support new tool ipmi-pet, tool to parse/interpret platform event traps. o Support new --sdr-cache-file option specify specific SDR cache file in all SDR related tools (ipmi-sensors, ipmi-sel, ipmi-fru, etc.). o In ipmi-fru, do not consider a busy device a fatal error. o In ipmi-sensors, support 'ignoreauthcode' workaround option. o In ipmi-sensors, support Quanta QSSC-S4R/Appro GB812X-CN OEM SDRs and sensors. o In ipmi-sel, support Quanta QSSC-S4R/Appro GB812X-CN OEM SEL events. o In ipmi-sel, fix several OEM specific event output bugs. o In ipmi-pef-config, fix configuration bug for Enable_PEF_Event_Messages. o In ipmi-raw, for file/stdin input, output line number when there is an error. Libraries - o Update libfreeipmi for DCMI 1.5 additions. o Update libfreeipmi fru-parse sub-library to support FRU parsing without an IPMI connection. o In libfreeipmi, support IPMI_FLAGS_NOSESSION flag to open a context for IPMI communication w/o establishing a session. o In libfreeipmi, support IPMI_FLAGS_NO_LEGAL_CHECK flag, to workaround motherboards to may return illegal IPMI packets. o In libfreeipmi, support IPMI_FLAGS_IGNORE_AUTHENTICATION_CODE flag, to workaround specific situations where motherboards return incorrectly generated authentication codes. o In libfreeipmi fru-parse sub-library, support IPMI_FRU_PARSE_ERR_DEVICE_BUSY error code. o In libfreeipmi, add support for IPMI firmware firewall and command discovery payloads. o In libfreeipmi, support Quanta QSSC-S4R/Appro GB812X-CN OEM SEL events. o Fix various macro names (typos, invalid naming, etc.) Contributions - o petalert.pl - snmptrapd handler script to alert when Platform Event Traps (PET) occur. Special thanks to Kaiwang Chen for his PET patches, contributions, and testing. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi support with HP iLO2 servers initial success!
## Possible values: Unspecified/Static/Use_DHCP/Use_BIOS/Use_Others IP_Address_Source Static ## Give valid IP address IP_Address192.168.xx.xx ## Give valid MAC address MAC_Address F4:CE:23:78:xx:06 ## Give valid Subnet Mask Subnet_Mask 255.255.255.0 ## Give valid IP address Default_Gateway_IP_Address192.168.xxx.xxx EndSection # # Section Lan_Conf_Auth Comments # # In the Lan_Conf_Auth section, allowable authentication mechanisms for IPMI 1.5 # is configured. Most users will want to set all MD5 authentication to Yes # and the rest to No. If you have configured a NULL username and a NULL # password, you will also want to configure some of the None fields to Yes # to allow None authentication to work. Some motherboards do not allow you to # enable OEM authentication, so you may wish to set all OEM related fields to # No. # Section Lan_Conf_Auth is something wrong with the settings? best regards john s. -- View this message in context: http://old.nabble.com/ipmi-support-with-HP-iLO2-servers-initial-success%21-tp29527071p33329019.html Sent from the FreeIPMI - Users mailing list archive at Nabble.com. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi support with HP iLO2 servers initial success!
RAKP Message 2 Response xxx.xxx.xxx.xxx: = xxx.xxx.xxx.xxx: RMCP Header: xxx.xxx.xxx.xxx: xxx.xxx.xxx.xxx: [ 6h] = version[ 8b] xxx.xxx.xxx.xxx: [ 0h] = reserved[ 8b] xxx.xxx.xxx.xxx: [ FFh] = sequence_number[ 8b] xxx.xxx.xxx.xxx: [ 7h] = message_class.class[ 5b] xxx.xxx.xxx.xxx: [ 0h] = message_class.reserved[ 2b] xxx.xxx.xxx.xxx: [ 0h] = message_class.ack[ 1b] xxx.xxx.xxx.xxx: IPMI RMCPPLUS Session Header: xxx.xxx.xxx.xxx: - xxx.xxx.xxx.xxx: [ 6h] = authentication_type[ 4b] xxx.xxx.xxx.xxx: [ 0h] = reserved1[ 4b] xxx.xxx.xxx.xxx: [ 13h] = payload_type[ 6b] xxx.xxx.xxx.xxx: [ 0h] = payload_type.authenticated[ 1b] xxx.xxx.xxx.xxx: [ 0h] = payload_type.encrypted[ 1b] xxx.xxx.xxx.xxx: [ 0h] = session_id[32b] xxx.xxx.xxx.xxx: [ 0h] = session_sequence_number[32b] xxx.xxx.xxx.xxx: [ 24h] = ipmi_payload_len[16b] xxx.xxx.xxx.xxx: IPMI RMCPPLUS Payload: xxx.xxx.xxx.xxx: -- xxx.xxx.xxx.xxx: [ BYTE ARRAY ... ] = payload_data[36B] xxx.xxx.xxx.xxx: [ 5Eh 0Dh 00h 00h 80h 1Dh 86h 00h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: IPMI Command Data: xxx.xxx.xxx.xxx: -- xxx.xxx.xxx.xxx: [ 5Eh] = message_tag[ 8b] xxx.xxx.xxx.xxx: [ Dh] = rmcpplus_status_code[ 8b] xxx.xxx.xxx.xxx: [ 0h] = reserved1[16b] xxx.xxx.xxx.xxx: [ 861D80h] = remote_console_session_id[32b] xxx.xxx.xxx.xxx: [ BYTE ARRAY ... ] = managed_system_random_number[16B] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ BYTE ARRAY ... ] = managed_system_guid[12B] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h EDh FEh DEh C0h ] xxx.xxx.xxx.xxx: [ EDh FEh DEh C0h ] best regards john s. -- View this message in context: http://old.nabble.com/ipmi-support-with-HP-iLO2-servers-initial-success%21-tp29527071p33341216.html Sent from the FreeIPMI - Users mailing list archive at Nabble.com. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.1.5 Released
http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.1.5.tar.gz FreeIPMI 1.1.5 - 05/17/12 - Tools -- o Support Supermicro OEM sensors/SEL on H8DGU-F motherboards. o In ipmiconsole, fix password length check bug. o In bmc-watchdog, fix --start-if-stopped and --reset-if-running options. o In ipmidetectd, fix usage output typos. o In ipmi-sensors-config, fix several parallel output corner cases. o For consistency to other tools, turn on quiet-caching if communicating with multiple hosts in bmc-device and ipmi-oem. o In ipmi-sensors, fix bug in which multiple workarounds could not be used or used in combination with bridging. o Fix start run levels in ipmidetectd init script. Libraries - o In libfreeipmi fru-parse API, handle additional device busy errors. Misc o Various documentation updates. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Ipmi-oem : passowrd verification timeout while not interactive
Hi Nicolas, I'm not sure why you would have this problem. It should be identical. Do all of the FreeIPMI tools on your system have this same behavior (ipmi-sensors, ipmi-fru, etc.) or is it only ipmi-oem? The 0.7.17.beta2 version is a maintenance branch in Debian that I presently don't maintain (the last FreeIPMI release in that series in 0.7.16, which I just tried and appears to work). I'm happy to look at the code, there may have been a simple backporting bug, but can't get access to their code repo right now. In the meantime, perhaps you can try one of the newer versions of FreeIPMI (I released 1.1.5 yesterday). There also appears to be some newer debian versions too. Al On Fri, 2012-05-18 at 01:38 -0700, Nicolas T wrote: Dear all, I've got troubles with ipmi-oem. I would like to script it into a bash script so I have to make in not interactive. While in my bash I type the following interactive command : ipmi-oem -h 10.10.7.93 -u myipmiuser -P -l User dell get-power-info And the password after the prompt, I can get the information below : Cumulative Energy Start Time : 12/22/11 - 16:59:49 Cumulative Energy: 565.25 kWh Peak Amp Time: 11/10/11 - 21:15:10 Peak Amp : 1.00 A Peak Watt Time : 11/10/11 - 21:14:30 Peak Watt: 243 W If I try to make in uninteractive, I always get a ipmi-oem: password verification timeout ipmi-oem -h 10.10.7.93 -u myipmiuser -p mypassword -l User dell get-power-info ipmi-oem -h 10.10.7.93 -u myipmiuser --password=mypassword -l User dell get-power-info ipmi-oem -h 10.10.7.93 -u myipmiuser -pmypassword -l User dell get-power-info Is this normal? How should I solve it please. I try to get info from a Dell IDRAC6. lanched on debian squeeze with ipmi-oem - 0.7.17.beta2 I've read it on the man page password verification timeout - Password verification has timed out. A password invalid error (described above) or a generic session timeout (described below) occurred. During this point in the protocol it cannot be differentiated which occurred. But can't get what i mean!!! Thank you, JC ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Ipmi-oem : passowrd verification timeout while not interactive
On Fri, 2012-05-18 at 10:32 -0700, Albert Chu wrote: Hi Nicolas, I'm not sure why you would have this problem. It should be identical. Do all of the FreeIPMI tools on your system have this same behavior (ipmi-sensors, ipmi-fru, etc.) or is it only ipmi-oem? The 0.7.17.beta2 version is a maintenance branch in Debian that I presently don't maintain (the last FreeIPMI release in that series in 0.7.16, which I just tried and appears to work). I'm happy to look at the code, there may have been a simple backporting bug, but can't get access to their code repo right now. Whoops, my bad. I did release a 0.7.17.beta2 tar.gz, but never released 0.7.17 (0.8.1 came out and I ended maintenance on that line). I know that there was a piece of code in ipmi-oem that was fairly unportable to newer systems and was fixed in FreeIPMI 1.0.8: FreeIPMI 1.0.8 - 10/27/11 - o Fix ipmi-raw and ipmi-oem allocation bug on newer systems, such as RHEL6. that could be your issue. Any chance you can update? If not I can work w/ the debian maintainer on a backport patch. Al In the meantime, perhaps you can try one of the newer versions of FreeIPMI (I released 1.1.5 yesterday). There also appears to be some newer debian versions too. Al On Fri, 2012-05-18 at 01:38 -0700, Nicolas T wrote: Dear all, I've got troubles with ipmi-oem. I would like to script it into a bash script so I have to make in not interactive. While in my bash I type the following interactive command : ipmi-oem -h 10.10.7.93 -u myipmiuser -P -l User dell get-power-info And the password after the prompt, I can get the information below : Cumulative Energy Start Time : 12/22/11 - 16:59:49 Cumulative Energy: 565.25 kWh Peak Amp Time: 11/10/11 - 21:15:10 Peak Amp : 1.00 A Peak Watt Time : 11/10/11 - 21:14:30 Peak Watt: 243 W If I try to make in uninteractive, I always get a ipmi-oem: password verification timeout ipmi-oem -h 10.10.7.93 -u myipmiuser -p mypassword -l User dell get-power-info ipmi-oem -h 10.10.7.93 -u myipmiuser --password=mypassword -l User dell get-power-info ipmi-oem -h 10.10.7.93 -u myipmiuser -pmypassword -l User dell get-power-info Is this normal? How should I solve it please. I try to get info from a Dell IDRAC6. lanched on debian squeeze with ipmi-oem - 0.7.17.beta2 I've read it on the man page password verification timeout - Password verification has timed out. A password invalid error (described above) or a generic session timeout (described below) occurred. During this point in the protocol it cannot be differentiated which occurred. But can't get what i mean!!! Thank you, JC ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] FreeIPMI compatibility with HP Proliant DL380 / DL385 Servers
: [ 0h] = session_id[32b] 10.20.61.210: [ 9h] = ipmi_msg_len[ 8b] 10.20.61.210: IPMI Message Header: 10.20.61.210: 10.20.61.210: [ 20h] = rs_addr[ 8b] 10.20.61.210: [ 0h] = rs_lun[ 2b] 10.20.61.210: [ 6h] = net_fn[ 6b] 10.20.61.210: [ C8h] = checksum1[ 8b] 10.20.61.210: [ 81h] = rq_addr[ 8b] 10.20.61.210: [ 0h] = rq_lun[ 2b] 10.20.61.210: [ 12h] = rq_seq[ 6b] 10.20.61.210: IPMI Command Data: 10.20.61.210: -- 10.20.61.210: [ 38h] = cmd[ 8b] 10.20.61.210: [ Eh] = channel_number[ 4b] 10.20.61.210: [ 0h] = reserved1[ 3b] 10.20.61.210: [ 0h] = get_ipmi_v2.0_extended_data[ 1b] 10.20.61.210: [ 3h] = maximum_privilege_level[ 4b] 10.20.61.210: [ 0h] = reserved2[ 4b] 10.20.61.210: IPMI Trailer: 10.20.61.210: -- 10.20.61.210: [ EEh] = checksum2[ 8b] 10.20.61.210: = 10.20.61.210: IPMI 1.5 Get Channel Authentication Capabilities Request 10.20.61.210: = 10.20.61.210: RMCP Header: 10.20.61.210: 10.20.61.210: [ 6h] = version[ 8b] 10.20.61.210: [ 0h] = reserved[ 8b] 10.20.61.210: [ FFh] = sequence_number[ 8b] 10.20.61.210: [ 7h] = message_class.class[ 5b] 10.20.61.210: [ 0h] = message_class.reserved[ 2b] 10.20.61.210: [ 0h] = message_class.ack[ 1b] 10.20.61.210: IPMI Session Header: 10.20.61.210: 10.20.61.210: [ 0h] = authentication_type[ 8b] 10.20.61.210: [ 0h] = session_sequence_number[32b] 10.20.61.210: [ 0h] = session_id[32b] 10.20.61.210: [ 9h] = ipmi_msg_len[ 8b] 10.20.61.210: IPMI Message Header: 10.20.61.210: 10.20.61.210: [ 20h] = rs_addr[ 8b] 10.20.61.210: [ 0h] = rs_lun[ 2b] 10.20.61.210: [ 6h] = net_fn[ 6b] 10.20.61.210: [ C8h] = checksum1[ 8b] 10.20.61.210: [ 81h] = rq_addr[ 8b] 10.20.61.210: [ 0h] = rq_lun[ 2b] 10.20.61.210: [ 13h] = rq_seq[ 6b] 10.20.61.210: IPMI Command Data: 10.20.61.210: -- 10.20.61.210: [ 38h] = cmd[ 8b] 10.20.61.210: [ Eh] = channel_number[ 4b] 10.20.61.210: [ 0h] = reserved1[ 3b] 10.20.61.210: [ 0h] = get_ipmi_v2.0_extended_data[ 1b] 10.20.61.210: [ 3h] = maximum_privilege_level[ 4b] 10.20.61.210: [ 0h] = reserved2[ 4b] 10.20.61.210: IPMI Trailer: 10.20.61.210: -- 10.20.61.210: [ EAh] = checksum2[ 8b] /usr/local/sbin/ipmi-sensors: connection timeout -- View this message in context: http://old.nabble.com/FreeIPMI-compatibility-with-HP-Proliant-DL380---DL385-Servers-tp33958110p33958110.html Sent from the FreeIPMI - Users mailing list archive at Nabble.com. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] Input on new ipmiseld daemon
Hey everyone, The next big release of FreeIPMI will include a new daemon called 'ipmiseld'. Similar to the ipmievd daemon w/ ipmitool, it monitors the IPMI SEL and logs those messages to the syslog so that everything is in one place. It adds many FreeIPMI-isms as additional features, including: - One daemon can monitor log multiple hosts w/ hostrange support (presently tested up to ~140 nodes) - Using the results from SEL event interpretations (i.e. is the SEL event nominal, warning, or critical), events can be filtered out before being logged. - SEL logs can be automatically cleared when full. - Log message formats are configurable using a printf-like style. I'm sure there can be issues with certain motherboards, so I would appreciate any input from anyone on this new tool/daemon. Any input on bugs, issues, or even better default values would be welcome. The latest alpha release with this code can be found here: http://alpha.gnu.org/gnu/freeipmi/freeipmi-1.2.0.alpha1.tar.gz Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] How do I use ipmi-sensors-config output (from remote server) with check_ipmi_sensors plugin in nagios?
On Mon, 2012-07-23 at 11:48 -0700, Brandon wrote: Hello Al, I want to thank you very much for your pointer to -x option to the plugin. It works as billed! Now I just have to resolve why I can't gain access while using the -f /path-to/ipmi.cfg and get an error: /usr/local/sbin/ipmi-sensors: password verification timeout But if I use the same info with -U, -P and -L options, it authenticates properly. I read about the CentOS 5 issues, but I am using CentOS 6 on one machines, and Windows on another.Any thoughts there? Thanks again, Brandon I don't maintain the script, so I can't speak if there's a bug/issue in that script. Does your config file work w/ ipmi-sensors directly? i.e. ipmi-sensors -h myhost --config-file=/path/my-ipmi.cfg Outside of a typo or something, not sure what it could be. It's always possible there's a bug in FreeIPMI. Is your password along any interesting boundaries (i.e. 16 bytes long, 20 bytes long) or has a special character in it? Al On Fri, Jul 20, 2012 at 4:36 PM, Albert Chu ch...@llnl.gov wrote: Hi Brandon, I assume you're using this nagios plugin: http://www.thomas-krenn.com/en/oss/ipmi-plugin.html There is probably some confusion. The -f option (you list as -F below, I assume you mean -f) is the general FreeIPMI conf file (usually /etc/freeipmi/freeipmi.conf). It's not the config file from ipmi-sensors-config. To deal with your problem, most users configure the script to eliminate sensors they don't want to monitor. It appears the check_ipmi_sensor script has a -x option to remove sensors they don't want to monitor. When calling ipmi-sensors directly, the option is the -R option. Hope that helps, Al On Fri, 2012-07-20 at 11:30 -0700, Brandon wrote: Hi All, I would like to know how I can tell check_ipmi_sensors plugin perl script to update its knowledge of a remote server . It currently sees that 8 fans are possible, and only reads 3 fans working. I have only 3 fans installed. The output from the ipmi-sensors-config command shows the proper number of fans ( as does the Supermicro IPMI View GUI utility.) Nagios however throws critical errors showing that 5 fans are at speed 0. I was hoping I could somehow use the output from ipmi-sensors-config --checkout put into a file, and transfer it to the nagios server, and whenever I make a call to the check_ipmi_sensors plugin, send that as a config file. However, if I try and use that file directly as -F $ARG$ argument for the config file, it goes into an UNKNOWN state and complain about line 1 unknown configuration option Section. Any pointers would be greatly appreciated. Thanks. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://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 ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmi support with HP iLO2 servers initial success!
: [ FFh] = sequence_number[ 8b] 10.0.0.177: [ 6h] = message_class.class[ 5b] 10.0.0.177: [ 0h] = message_class.reserved[ 2b] 10.0.0.177: [ 0h] = message_class.ack[ 1b] 10.0.0.177: RMCP Command Data: 10.0.0.177: -- 10.0.0.177: [BE11h] = iana_enterprise_number[32b] 10.0.0.177: [ 80h] = message_type[ 8b] 10.0.0.177: [ BFh] = message_tag[ 8b] 10.0.0.177: [ 0h] = reserved[ 8b] 10.0.0.177: [ 0h] = data_length[ 8b] pong timed out: message_tag=191 :/ The BMC isn't supported by the Kernel though: bmc-config --checkout somewhow hangs as well as bmc-info It is also not listed via dmidecode --type 38 but there is one for sure. If it isn't listed by dmidecode, it's possible the HP board has IPMI at an unadvertised (and unfortunately non-default) address. The hang is likely b/c IPMI is trying to communicate at the default and is just not getting a response. Does HP provide any instructions that would allow you to input addresses to options like --driver-address? It's a very old System so I don't think there's anything. The web interface works so far and the virtual console (also web interface) works as well. I don't know if there is a workaround to get iLO2 working but I would like to be able to use it though. It's a ProLiant DL380 G4. Wouldn't know anything for this particular issue, but the following workaround was added for other HP machines: assumeio - This workaround option will assume inband interfaces communicate with system I/O rather than being memory-mapped. This will work around systems that report invalid base addresses. Those hitting this issue may see device not supported or could not find inband device errors. Issue observed on HP ProLiant DL145 G1. I just tried bmc-info -W assumeio but it doesn't work either :/ Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Duplicate Sensors on a Dell PowerEdge R310
| Entity Presence | Nominal | N/A| N/A | 'Entity Present' 40 | USB Cable Pres | Entity Presence | Nominal | N/A| N/A | 'Entity Present' 41 | Riser2 Pres | Entity Presence | Nominal | N/A| N/A | 'Entity Present' 42 | Riser1 Pres | Entity Presence | Nominal | N/A| N/A | 'Entity Present' 44 | Status | Processor| Nominal | N/A| N/A | 'Processor Presence detected' 45 | Status | Power Supply | Nominal | N/A| N/A | 'Presence detected' 46 | Status | Power Supply | Nominal | N/A| N/A | 'Presence detected' 47 | Status | Cable/Interconnect | Nominal | N/A| N/A | 'Cable/Interconnect is connected' 48 | iDRAC6 Ent Pres | Entity Presence | Critical | N/A| N/A | 'Entity Absent' 49 | OS Watchdog | Watchdog 2 | Nominal | N/A| N/A | 'OK' 51 | Intrusion| Physical Security| Nominal | N/A| N/A | 'OK' 52 | PS Redundancy| Power Supply | Nominal | N/A| N/A | 'Fully Redundant' 53 | Fan Redundancy | Fan | Nominal | N/A| N/A | 'Fully Redundant' 56 | Drive| Drive Slot | Nominal | N/A| N/A | 'Drive Presence' 57 | Cable SAS A | Cable/Interconnect | Nominal | N/A| N/A | 'Cable/Interconnect is connected' 58 | Current 1| Current | Nominal | 0.48 | A | 'OK' 59 | Current 2| Current | Nominal | 0.48 | A | 'OK' 60 | Voltage 1| Voltage | Nominal | 122.00 | V | 'OK' 61 | Voltage 2| Voltage | Nominal | 120.00 | V | 'OK' 62 | System Level | Current | Nominal | 140.00 | W | 'OK' 63 | Power Optimized | OEM Reserved | Nominal | N/A| N/A | 'Good' 65 | DKM Status | OEM Reserved | N/A | N/A| N/A | 'OEM Event = h' As you can see, sensor 36 and 48 are duplicated. IMHO that shouldn't happen. I guess it's something Dell specific. Is there anything I could do to help to get that fixed? Like offering additional information. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.2.1 Released
. - For example: ipmi_sdr_cache_ctx_t - ipmi_sdr_ctx_t ipmi_sdr_parse_ctx_t - ipmi_sdr_ctx_t ipmi_sdr_cache_ctx_create() - ipmi_sdr_ctx_create() ipmi_sdr_parse_ctx_destroy() - ipmi_sdr_ctx_destroy() IPMI_SDR_CACHE_ERR_PERMISSION - IPMI_SDR_ERR_PERMISSION IPMI_SDR_PARSE_ERR_PARAMETERS - IPMI_SDR_ERR_PARAMETERS - Please see the new ipmi-sdr.h header file for full changes. o In libfreeipmi, create new 'sel' sub-library which replaces the 'sel-parse' library. - This results in an ABI change. Generally speaking, all ipmi_sel_parse functions, types, and macros are changed to ipmi_sel, although some minor exceptions exist. - For example: ipmi_sel_parse_ctx_t - ipmi_sel_ctx_t ipmi_sel_parse_ctx_destroy() - ipmi_sel_ctx_destroy() IPMI_SEL_PARSE_ERR_PARAMETERS - IPMI_SEL_ERR_PARAMETERS - Please see the new ipmi-sel.h header file for full changes. o In libfreeipmi, create new 'fru' sub-library which replaces the 'fru-parse' library. - This results in an ABI change. Generally speaking, all ipmi_fru_parse functions, types, and macros are changed to ipmi_fru, although some minor exceptions exist. - For example: ipmi_fru_parse_ctx_t - ipmi_fru_ctx_t ipmi_fru_parse_ctx_destroy() - ipmi_fru_ctx_destroy() IPMI_FRU_PARSE_ERR_PARAMETERS - IPMI_FRU_ERR_PARAMETERS - Please see the new ipmi-fru.h header file for full changes. o In libfreeipmi, support Cipher Suite 15 and 16 implementation based on comments from Intel. o In libfreeipmi, add Cipher Suite 18 and 19 information, but do not support. o In libfreeipmi, support SEL string output format '%E' for combined event data1, data2, and data3 output. o In libfreeipmi, support SEL string output format '%I' for interpretation event output. o In libfreeipmi, fix bug in SEL string output in which both sensor name and severity used '%s'. Severity now uses '%S'. o In libfreeipmi, support ability to config interpret config file and sel library and receive appropriate error. o In libfreeipmi, support reservation-id registration and clearing in the sel sub-library. o In libfreeipmi, sel sub-library now supports a no sel entries loaded error. o In libfreeipmi, condense sel record parsing functions. One set of functions now handles the previous case of both sets. o In libfreeipmi, fru sub-library now supports ipmi_fru_parse_read_multirecord_record_type_id function. o In libfreeipmi, support additional sensor/SEL interpretations, including: - OS Boot - OS Critical State State - Platform Alert State - Boot Error State - System Event Transition State o In libfreeipmi, add missing macro definitions. o In libipmimonitoring, support Cipher Suite ID 15, 16, and 17. o In libfreeipmi, libipmiconsole, libipmimonitoring, support ability to specify alternate port via optional [:port] in hostname. o In libfreeipmi, add additional IPMI commands/payloads. o In libfreeipmi, fix several macro names which did not meet standardization needs. o In libfreeipmi, support new IPMI_ERR_DRIVER_BUSY error code. o In libfreeipmi sdr, support more complete parsing of Management Controller Locator Records. o In libfreeipmi, KCS driver now sleeps a small amount between IPMB retries to avoid spinning. o In libfreeipmi and libipmimonitoring, do not export functions that shouldn't be. o In libfreeipmi, support stats functions and new utility functions in sdr sub-library. o In libfreeipmi, sel sub-library now supports the output of entity sensor names. o In libfreeipmi, fru sub library now supports new function to determine multirecord type. o In libfreeipmi, fix argument size bugs with Intel Node Manager functions. o In libipmimonitoring, support entity sensor name output options. Misc o Add diagnostic/exit-value information to most manpages. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] ipmitools with IPMI BMC KCS
Can you try running ipmi-locate? Lets see if ipmi-locate can even find a IPMI card on your system. Maybe i need some driver actived in the kernel ? Usually you don't need to, but installing/running the Linux IPMI kernel driver is worth trying. If you're on Linux w/ most distros /etc/init.d/ipmi start should start it up. Al On Sun, 2012-09-09 at 00:26 -0700, Fabio Cecamore wrote: Hi Al, thanks for your reply, the workaround this time dont work :( root@ProLiant:/home/fabio# ipmi-sensors -W assumeio could not find inband device root@ProLiant:/home/fabio# [146841.244016] ipmi-sensors:6367 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back [146841.245030] ipmi-sensors:6367 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back [146841.245052] ipmi-sensors:6367 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back Maybe i need some driver actived in the kernel ? -Messaggio originale- From: Al Chu Sent: Sunday, September 09, 2012 6:12 AM To: Fabio Cecamore Cc: freeipmi-users@gnu.org Subject: Re: [Freeipmi-users] ipmitools with IPMI BMC KCS Hi Fabio, Some HP motherboards have a bug which does not advertise properly it's KCS device information. Here's the workaround option from the manpage assumeio - This workaround flag will assume inband interfaces communicate with system I/O rather than being memory-mapped. This will work around systems that report invalid base addresses. Those hitting this issue may see device not supported or could not find inband device errors. Issue observed on HP ProLiant DL145 G1. It'd be worth a shot trying it out (via -W assumeio). Al On Sat, 2012-09-08 at 16:14 -0700, Fabio Cecamore wrote: Hello at all, i’m trying to use freeipmi tools in my debian installation (on a microserver proliant hp) but there is no way to work.. root@ProLiant:~# bmc-info could not find inband device root@ProLiant:~# ipmi-sensors could not find inband device root@ProLiant:~# in dmesg: [117664.327176] bmc-info:5860 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back [117664.327197] bmc-info:5860 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back [117664.328223] bmc-info:5860 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back [117664.329762] bmc-info:5860 map pfn expected mapping type uncached-minus for d7fa-d7fa1000, got write-back I'm sure i've a ipmisensors becouse this is the output of lm_sensors: Driver `ipmisensors': * ISA bus Chip `IPMI BMC KCS' (confidence: 8) But lm_sensors have not the driver too and not work.. What can i try ? Thank you Bye Fabio C. ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
[Freeipmi-users] FreeIPMI 1.2.2 Released
http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.2.2.tar.gz FreeIPMI 1.2.2 - 10/02/12 - Tools -- o Support new --sol-payload-instance and --deactivate-all-instances options in ipmiconsole. o Fix ipmiseld compile issue with -Werror=format-security. Libraries - o In libipmiconsole, add new ipmiconsole_ctx_set_config() and ipmiconsole_ctx_get_config() functions. o In libipmiconsole, add support for specifying and handling different SOL payload instances. This support includes: - Support new IPMICONSOLE_CTX_CONFIG_OPTION_SOL_PAYLOAD_INSTANCE configuration option. - In libipmiconsole, support new IPMICONSOLE_BEHAVIOR_DEACTIVATE_ALL_INSTANCES behavior flag. - Return more appropriate error codes when activation limits are discovered. o In libfreeipmi, fix debug output corner case when outputting byte arrays. Misc o Various documentation updates and fixes. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
Re: [Freeipmi-users] Processor 2 Presence: entity absent
Hi Tiago, I think the best option is to specify to ipmimonitoring the specific sensors you don't want reported (-R). This is easy if you're scripting something. If you're not, defaults can be configured into /etc/freeipmi/freeipmi.conf so you don't have to type it every time (note that the config would be through ipmi-sensors not ipmimonitoring. ipmimonitoring is a script around ipmi-sensors). A slightly more advanced option is to try and disable this sensor via ipmi-sensors-config. Advanced sensor configuration can be tricky and motherboards don't always like it/work well with it b/c vendors typically assume the user will never try to change their defaults. This latter option isn't one I recommend for more inexperienced folks. Al On Wed, 2012-10-10 at 17:16 +0100, Tiago Vasconcelos wrote: Hi I have installed freeipmi 1.2.1 on a Dell PowerEdge R415, where ipmimonitoring outputs the following Critical state: 48 | Processor 2 Presence | Entity Presence | Critical | 'Entity Absent' The system is meant to have a single processor. So I don't want ipmi to complain about the absence of a second processor. I have browsed the iDRAC interface but I couldn't find out how I can get rid of this Critical alert. Does anyone know? Tiago ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-users mailing list Freeipmi-users@gnu.org https://lists.gnu.org/mailman/listinfo/freeipmi-users
