Re: [Freeipmi-devel] interruptible driver calls
Bmc-watchdog uses the interruptible functions. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Tuesday, April 19, 2005 5:07 pm Subject: [Freeipmi-devel] interruptible driver calls Any one using ipmi_kcs_cmd_raw_interruptible or ipmi_kcs_cmd_interruptible calls? If no one uses them, I will not include interruptible calls in the initial release of new unified driver model. -- Anand Babu GPG Key ID: 0x62E15A31 Personal Blog [http://freedom.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Old libfreeipmi bug fix
Hey Andrew, I remember the patch. I wasn't quite sure why it didn't make it into 0.1.3. Then I looked at the tag and ChangeLog dates. The fix was applied post 0.1.3 :-( By the way, I believe you want from = sizeof(struct sockaddr_in) in your patch if you were applying it locally. Also didn't we fix the sequence numbering problem in ipmiutil userspace?? I dug up and e-mail showing I gave you this: rv = ipmi_lan_cmd(sockfd, hostaddr, hostaddr_len, auth_type, session_seqnum, session_id, authcode, authcode_len, netfn, IPMI_BMC_IPMB_LUN_BMC, (rq_seq % (IPMI_LAN_SEQ_NUM_MAX + 1)), cmd_rq, tmpl_rq, cmd_rs, tmpl_rs); Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Cress, Andrew R [EMAIL PROTECTED] Date: Friday, May 13, 2005 9:00 am Subject: Old libfreeipmi bug fix Al, For some reason, the fix from the thread below didn't get propagated into libfreeipmi-0.1.3. I ran into it again. I have attached the patch I applied to make it work for me. I also created bug #13076 for it, so we don't lose track of it again :-). Andy -Original Message- From: Albert Chu [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 12:20 PM To: Cress, Andrew R Cc: freeipmi-devel@gnu.org Subject: Re: RE: [Freeipmi-devel] Using libfreeipmi interface Hi Andrew, You're right that it needs to be initialized, but I think it has to be initialized to sizeof(struct sockaddr_in). _pkt_len is probably a largeenough size that it just happened to work. Thanks for the catch Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Cress, Andrew R [EMAIL PROTECTED] Date: Wednesday, October 27, 2004 2:09 pm Subject: RE: [Freeipmi-devel] Using libfreeipmi interface Albert, I did find the problem that was causing the recvfrom to abort. In libfreeipmi/src/ipmi-lan-interface.c at about line 699: fromlen = _pkt_len; /* added this, fromlen must be initialized */ pkt_len = ipmi_lan_recvfrom (sockfd, pkt, _pkt_len, 0, (struct sockaddr *)from, fromlen); There may be other places that call recvfrom where this change would be needed also. It works now, if the app is careful with sequence numbers. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cress, Andrew R Sent: Wednesday, October 27, 2004 2:07 PM To: Albert Chu Cc: freeipmi-devel@gnu.org Subject: RE: [Freeipmi-devel] Using libfreeipmi interface Albert, I have been able to get the kcs interface working with the FreeIPMI library, but not yet the LAN interface. I'm using ipmi_lan_open_session() and ipmi_lan_cmd(), and I put in some debug statements in ipmi-lan-interface.c. The ipmi_lan_open_session fails at the Get_Session_Challenge command response. I'm confused as to why ipmi_lan_recvfrom returns -1 for this command. The ipmipower app does get status ok, but gets invalid authtype tryingto reset. The remote node does respond to BMC LAN commands via other (Intel) server management applications, and I've included its configuration information below. Attempting to open_session to remote node: assemble_ipmi_lan_pkt complete cmd=38 ipmi_lan_sendto status = 23 ipmi_lan_recvfrom len = 30 unassemble complete get_chan_auth rsp: 38 00 07 17 01 00 00 00 00 00 ipmi_comp_test complete status = 1 assemble_ipmi_lan_pkt complete cmd=39 get_sess_chal rq: 39 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ipmi_lan_sendto status = 38 ipmi_lan_recvfrom len = -1 ipmi_lan_open_session: rv = -1 id=0 BMC LAN Configuration of remote node: Lan Param(0) Set in progress: 00 Lan Param(1) Auth type support: 17 Lan Param(2) Auth type enables: 17 17 06 06 00 Lan Param(3) IP address: 10 243 42 182 Lan Param(4) IP addr src: 01 Lan Param(5) MAC addr: 00 03 47 94 ff 46 Lan Param(6) Subnet mask: 255 255 255 0 Lan Param(7) IPv4 header: 40 40 10 Lan Param(10) BMC grat ARP : 01 Lan Param(11) grat ARP interval: 04 Lan Param(12) Def gateway IP: 10 243 42 251 Lan Param(13) Def gateway MAC: 00 05 9a da d3 fc Lan Param(14) Sec gateway IP: 0 0 0 0 Lan Param(15) Sec gateway MAC: 00 00 00 00 00 00 Lan Param(16) Community string: public Lan Param(17) Num dest: 04 Lan Param(18) Dest type: 01 00 01 00 69 Lan Param(19) Dest address: 01 00 00 [10 243 42 182] 00 03 47 94 ff 46 Lan Param(192) DHCP Server IP: 0 0 0 0 Lan Param(193) DHCP MAC Address: 00 00 00 00 00 00 Lan Param(194) DHCP Enable: 00 GetChanAcc(lan), ret = 0, new value = 02 Access = Always Avail, PEF Alerts Enabled Lan Param(201) Channel Access Mode(Lan): 02 04 Get User Access(1): 04 01 00 14 -Original Message- From: Albert Chu [mailto:[EMAIL PROTECTED
[Freeipmi-devel] [bug #13076] ipmi_lan_open_session error -1 with libfreeipmi-0.1.3
Update of bug #13076 (project freeipmi): Open/Closed:Open = Closed ___ Follow-up Comment #1: patch was applied post 0.1.3 :-( Its already in 0.2.0 Al ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=13076 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] using gcrypt
Any issues if we switch over to gcrypt for md5, md2, hmac, sha, and all future digest/encryption/etc. in libfreeipmi? Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Need to issue commands to non-BMC slave addresses
Hey Andrew, Comments/advice? For lan, in the short term, I think the best thing to do is to use the fiid_obj_set() function to manually set the field rs_addr of the tmpl_lan_msg_hdr_rq template. I'm not quite sure what to for KCS though. As far as I can tell, it can only go to the BMC and nothing else. According to the IPMI 2.0 spec, beginning of Chapter 9. The KCS interface is specified solely for SMS messages indicating it can't be done?? AB, your thoughts? For the long term though, I believe this has to be fixed in the libfreeipmi library API somehow. We simply assume all transactions go to the BMC slave address, but its apparently not a correct assumption. I'll add it to the todo list. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Cress, Andrew R [EMAIL PROTECTED] Date: Wednesday, May 25, 2005 8:50 am Subject: [Freeipmi-devel] Need to issue commands to non-BMC slave addresses In my utilities, there are a few cases where IPMI commands (for FRU) need to be sent to a slave address other than the BMC slave address (0x20). For instance, in our platforms the HotSwap Controller has IPMIFRU data at slave address 0xC0. I currently have no way of passing a different slave address to ipmi_kcs_cmd_interruptible() or ipmi_lan_cmd(). I noticed that fill_lan_msg_hdr() inserts a constant BMC slave address,but I didn't find where the kcs template had a place for the slave address. Comments/advice? Andy ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: RE: [Freeipmi-devel] FreeBSD 5.4 / freeipmi 0.1.3 w/ Intel SE7210 motherboard
Ahhh, the National Semiconductor BMC. Another user had problems with that BMC. It was replying to 'ipmipower' with invalid sequence numbers. A workaround is already commited in CVS. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Mitch (Bitblock) [EMAIL PROTECTED] Date: Monday, June 20, 2005 3:27 pm Subject: RE: [Freeipmi-devel] FreeBSD 5.4 / freeipmi 0.1.3 w/ Intel SE7210 motherboard Hi Al - not sure, if you are referring to the BMC, it's a National Semiconductor PC87431 - the brand is Intel if you were asking about themanufacturer. Anand says it's being worked on and will be in CVS after his next commit(found that out off list while the mailman settings were being worked on) cheers m/ Hi Mitch, The SE7210 is a Tiger4?? Al ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeBSD 5.4 / freeipmi 0.1.3 w/ Intel SE7210
I did not know about this issue. GNU Coding Standards recommends argp library. Currently some tools uses argp library and some getopt. I think it is better to use argp uniformly through out the code base. We will take care of this bug in the next release. (Albert can you take care of this bug?) Sure, I'll add it to my list of todo's. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Monday, June 20, 2005 3:29 pm Subject: Re: [Freeipmi-devel] FreeBSD 5.4 / freeipmi 0.1.3 w/ Intel SE7210 ,[ Mitch (Bitblock) [EMAIL PROTECTED] ] | Hi Mitch, | There was a problem in Mailman settings. I screwed up the setting | while I was trying to filter out spam. I think I have fixed it | now. Please try and and let me know if it works. | | [Mitch says:] I resent just a few minutes ago... hopefully it will | go through ok ;-) don't see an echo or a rejection yet though ` I found the problem now. Even though I restored the working configuration for few new members moderation bit was set. So I have to explicitly approve your previous message. I reset moderation bit to off for all. I hope Mailman should behave OK from now on. Thanks. , | As an aside, one thing I didn't see documented was the reason for | the prompt to use set_io (the name was longer - can't remember it, | and rerunning config does not ask the question again even after a | make distclean) vs. io (4)? | | I didn't see the option detailed in the PDF or anywhere else or any | details of what to choose or why / when? | | Also, the troubleshooting section might make reference to the fact | that if it just hangs like mine does that it may mean support for | your chipset / board is not included yet? Or is that a bug? ` Device IO port can be set at run time either thru config file or command line argument. For 0.2.0 we are trying to detect device automatically as much as possible. We also added ACPI based probing recently. But you are correct. I will have to document in detail what the user should to and look for if it hangs in the first place. Thanks for pointing out that. , | I also tried building freeipmi on some older Intel STL2 systems | (FreeBSD 4.8) - to get it work work, I had to manually add port: ` Older Intel STL2 motherboards should use IPMI-1.0. I am glad it works. Please tell us the port number that worked for you. I will make the device detection code match it with product/manufacturer id and return this port internally. , | argp-standalone-1.3 And remove references to getopt. FreeBSD uses | unistd, which seems to have been detected, but the separate | references to getopt were not removed - is this a configure bug? | Sorry I'm not a C coder | | grep -r getopt.h * | vi work/freeipmi-0.1.3/bmc-watchdog/src/bmc-watchdog.c | vi work/freeipmi-0.1.3/ipmipower/src/ipmipower_config.c | vi work/freeipmi-0.1.3/libfreeipmi/src/ipmi-ping.c | | I just dd'd the #include getopt.h lines. ` I did not know about this issue. GNU Coding Standards recommends argp library. Currently some tools uses argp library and some getopt. I think it is better to use argp uniformly through out the code base. We will take care of this bug in the next release. (Albert can you take care of this bug?) , | After making, I ran bmc-info - which kindof works - I saw the | reference to the cat in the troubleshooting section - but this is | included code - should I have to edit the code? | | vi /usr/local/share/fish/extensions/utils.scm | ;; (use-modules (srfi srfi-13)) | vi /usr/local/share/fish/extensions/sensors.scm | ;; (use-modules (srfi srfi-13)) | ;; (use-modules (srfi srfi-14)) | | Commenting those lines got rid of a few of the errors... Where do I | go from here? | | | ./bmc-info | | --: --: --: --: | ~ ~ Cat ate the fish!! ~ ~ | --: --: --: --: | Fish Exception (gh_standard_handler dump): | tag: misc-error | throw args : (#f ~A ~S (no such module (srfi srfi-13)) #f) | data : [/usr/local/share/fish/extensions/utils.scm] | No backtrace available. | | | --: --: --: --: | ~ ~ Cat ate the fish!! ~ ~ | --: --: --: --: | Fish Exception (gh_standard_handler dump): | tag: misc-error | throw args : (#f ~A ~S (no such module (srfi srfi-13)) #f) | data : [/usr/local/share/fish/extensions/sensors.scm] | No backtrace available. | | | --: --: --: --: | ~ ~ Cat ate the fish!! ~ ~ | --: --: --: --: | Fish Exception (gh_standard_handler dump): | tag: unbound-variable | throw args : (#f Unbound variable: ~S (system-error-errno) #f) | data : [/usr/local/share/fish/extensions/bc-common.scm] | No backtrace available. | | Device ID: 1 | Device Revision: 0 |[SDR Support] | Firmware Revision: 1.16 |[Device Available (normal
Re: [Freeipmi-devel] ipmi_lan_open_session() question
Yeah that was a typo Didn't fix my problem though.
Hmmm. Does something like 'ipmipower' atleast work?
Al
--
Albert Chu
[EMAIL PROTECTED]
Lawrence Livermore National Laboratory
- Original Message -
From: James Laros [EMAIL PROTECTED]
Date: Tuesday, September 27, 2005 4:12 pm
Subject: Re: [Freeipmi-devel] ipmi_lan_open_session() question
On 16:07 Tue 27 Sep , Albert Chu wrote:
Hi Jim,
I think the open_lan_session() function was created a long time
ago as a
convenience function for libfreeipmi users. I know that the
ipmiutil author (ipmiutil.sourceforge.net) atleast uses it. I
suppose it has
never been used for the FreeIPMI tools because:
A) some tools like bmc-config only work in-band
B) some tools like ipmipower need to work more reliably/quickly and
therefore manually setup a lan session
This was the first direction I went and hit a bump with extracting the
temp session id. If I can't get past it I will send out a question.
As for the reason why your code isn't working with MD5, I'm
guessing:
sizeof(password),
should instead be
strlen(password)
Yeah that was a typo Didn't fix my problem though.
???
By the way it seems to return 0 but set errno to Success??
I see a few corner cases in the code. In particular the fallout
case for goto error;. I'll let AB talk about this since its his
part of
the lib :P
Al
--
Albert Chu
[EMAIL PROTECTED]
Lawrence Livermore National Laboratory
- Original Message -
From: James Laros [EMAIL PROTECTED]
Date: Tuesday, September 27, 2005 2:51 pm
Subject: [Freeipmi-devel] ipmi_lan_open_session() question
I have a question about the usage of ipmi_lan_open_session.
First off I don't see it used in any of the utilities
that come with the distro? Any reason?
I was doing things more by hand as in ipmipower until
I noticed this call.
More specific question if I use the call as follows the
Activate Session Application Response returns a completion
code of 0xcc (Invalid data field in request)
Wasn't sure if I need to pass in something for session_seq_num
or session_id??? In the request message the session_id seems be
set properly to a temp session id, session_seq is 0 which
should be
ok yes?
Note that if I run it with MD5 as an auth type and provide
username and password I never get an app response.
By the way it seems to return 0 but set errno to Success??
--
u_int8_t auth_type;
u_int8_t *username = root;
u_int8_t *password = yada;
u_int8_t priv;
priv = IPMI_PRIV_LEVEL_OPERATOR;
u_int32_t *session_seq_num;
u_int32_t *session_id;
session_seq_num = (u_int32_t *)malloc(sizeof(u_int32_t));
session_id = (u_int32_t *)malloc(sizeof(u_int32_t));
auth_type = IPMI_SESSION_AUTH_TYPE_MD5;
if (ipmi_lan_open_session(conn-fd,
(struct sockaddr *)(conn-
target_addr), sizeof(struct
sockaddr_in), IPMI_SESSION_AUTH_TYPE_NONE,
// auth_type,
username,
// password,
// sizeof(password),
NULL,
0,
INITIAL_OUTBOUND_SEQ_NUM,
priv,
session_seq_num,
session_id) 0 ) {
fprintf(stderr, Error: ipmi_lan_open_session %s\n,
strerror(errno));return -1;
}
---
Thanks if anyone can help.
Jim
--
__
James Laros ... [EMAIL PROTECTED]
Dept. 09224
Scalable Systems Integration .. PHONE:505.845.8532
Sandia National Labs FAX:505.844.9297
__
Is someone getting the best of you?
- Foo Fighters
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
--
__
James Laros ... [EMAIL PROTECTED]
Dept. 09224
Scalable Systems Integration .. PHONE:505.845.8532
Sandia National Labs FAX:505.844.9297
__
Is someone getting the best of you?
- Foo Fighters
___
Freeipmi-devel
[Freeipmi-devel] ipmiping 2.0 patch
Does someone out there have a ipmi 2.0 machine[1] that could sanity check this patch?? After applying and compiling, try: ipmiping -r 2.0 hostname and ipmiping -r 2.0 -v hostname Thanks, Al [1] - That we believe is actually compliant to some degree or another. -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] ipmi 2.0 branch
Ab, Bala, etc., I'm starting some development in the branch 'al_ipmi_2_0_branch'. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] gcrypt
AB, Bala, Argh! So libgcrypt doesn't implement md2. According to the docs: GCRY_MD_MD2 This is an reserved identifier for MD-2; there is no implementation yet. After thinking about it for a minute or two on the best way deal with this, I've decided to keep the current code for IPMI 1.5. In other words, we'll stick with the MD2 and MD5 libraries I added into libfreeipmi from ipmipower. I'll be removing my SHA1 and HMAC code in favor of gcrypt for all IPMI 2.0 stuff. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmi 2.0 branch
I am thinking if you should start IPMI-2.0 work in the current branch itself. We can always say 2.0 support as experimental. Otherwise you will still have to go thru the pain of merging at some point. I think I'll keep it in a branch. I guess it's development philosophy differences. I'm not a big fan of dumping very new untested experimental code into a soon to be new release. Remember, I release this code into our production environment :-) I should have made a test release 2 weeks ago. But Bala got struck with the new LAN stack as he is developing on a remote system. It has a bug. It seems to lock the BMC for auth-types other than AUTH_TYPE_NONE and the system needs physical power-cycle (removing the power chord). Can you continue his work and see what went wrong in the new code. Are you referring to the unified driver stuff? I can take a look. Just point me in the direction of what new API calls/options/whatever aren't working. Al -- Albert Chu [EMAIL PROTECTED] Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Thursday, November 3, 2005 6:50 pm Subject: Re: [Freeipmi-devel] ipmi 2.0 branch ,[ Albert Chu [EMAIL PROTECTED] ] | Ab, Bala, etc., | I'm starting some development in the branch 'al_ipmi_2_0_branch'. ` I am thinking if you should start IPMI-2.0 work in the current branch itself. We can always say 2.0 support as experimental. Otherwise you will still have to go thru the pain of merging at some point. I should have made a test release 2 weeks ago. But Bala got struck with the new LAN stack as he is developing on a remote system. It has a bug. It seems to lock the BMC for auth-types other than AUTH_TYPE_NONE and the system needs physical power-cycle (removing the power chord). Can you continue his work and see what went wrong in the new code. I suspect it has to do with session and session-auth header. After you fix this bug, I want add support for per-message-auth-disable. This means if lan-channel-auth-caps reports per-message-auth as disabled, then session-auth will be used only during session initiation. Bala will take care of this. Immediately after finishing this we will make a test release. I am still travelling and should be back on 11th. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [sr #104828] support option to delete a range of sel entries
URL: http://savannah.gnu.org/support/?func=detailitemitem_id=104828 Summary: support option to delete a range of sel entries Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Fri 11/11/05 at 15:44 Category: ipmi-sel Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Platform Version: None ___ Details: for example sel --delrange 50 800 deletes sel entries with id 50 to 800 ___ Reply to this item at: http://savannah.gnu.org/support/?func=detailitemitem_id=104828 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: how to join the freeipmi development
Hi Cory, We mostly communicate through e-mail and this mailing list. We are both based out of San Francisco, CA, so we have met on occassion (I think 3-4 times in 2+ years?). The short-term issue that I feel is most important right now is to have a sanity testsuite. My plan was to develop a set of scripts that would cover a large base of the functionality of the FreeIPMI tools. The scripts would do sanity checks on the output and such. A.B., could you describe what you were thinking of for the FreeIPMI testsuite. My ideas may be different than what you were planning. Long term IPMI 2.0 and SOL is certainly most important. I have already begun IPMI 2.0 development in the CVS branch al_ipmi_2_0_branch. I am perhaps half-done completing the base code in libfreeipmi so that ipmi 2.0 work can be done in all of the tools. Admittedly this development is a bottle-neck. After it is complete though, IPMI 2.0 work can be done in parallel in the various FreeIPMI tools, which we be very welcome to have you help with :-) Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: coly li [EMAIL PROTECTED] Date: Thursday, December 8, 2005 9:47 pm Subject: Re: how to join the freeipmi development Chu: In defact, I'm not very clear what could I do now. I want to do something on IPMI 2.0, including driver, application, documentation, all are ok. just help IPMI 2.0 to be ready in opensource. I plan to borrow a sahalee board in these months, and then, I can do some testing and bugfix. I just wander how the team members communicate to each other, how I canget all development informations. Coly ? 2005-12-08?? 20:26 -0800?Albert Chu??? Hi Coly, Actually, I should also ask what kind of ideas do you have. Was there any kind of testsuite or work you were interested in doing? Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Thursday, December 8, 2005 8:22 pm Subject: Re: [Freeipmi-devel] FreeIPMI meeting notes + Todos Hi Coly, I'm glad to hear about your interest in working on FreeIPMI. Actually,myself and A.B. spoke about starting a testsuite soon. We still need to flesh out some details, but if you'd like to help, we can always use the extra help. Al ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] FreeIPMI testsuite
Hey A.B., I wanted to start discussions on the FreeIPMI testsuite. What are your ideas? My ideas are (for the initial start of the testsuite), scripts that: A) run the user command tools with various permutations of options B) sanity check the output (i.e. are temperatures 0 and 1000 degrees Celsius) C) over LAN and In-Band There would have to be a config file that the user must input IP addresses, usernames, and etc. What are your ideas? Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Thursday, December 8, 2005 8:26 pm Subject: Re: [Freeipmi-devel] FreeIPMI meeting notes + Todos Hi Coly, Actually, I should also ask what kind of ideas do you have. Was there any kind of testsuite or work you were interested in doing? Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Thursday, December 8, 2005 8:22 pm Subject: Re: [Freeipmi-devel] FreeIPMI meeting notes + Todos Hi Coly, I'm glad to hear about your interest in working on FreeIPMI. Actually,myself and A.B. spoke about starting a testsuite soon. We still need to flesh out some details, but if you'd like to help, we can always use the extra help. Al -- Albert Chu [EMAIL PROTECTED] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: coly li [EMAIL PROTECTED] Date: Thursday, December 8, 2005 5:42 pm Subject: Re: [Freeipmi-devel] FreeIPMI meeting notes + Todos Hi,every one. I just join this maillist these days. I've worked on IPMIfor three years, including driver, FW and system software. I want to do something for this project, for example writing some testsuite, or documentations. Where can I start ? Coly ? 2005-12-08?? 11:23 -0800?Albert Chu??? MEETING NOTES Compliance Testing: Linux IPMI Test Suite - Use testsuites for major open source applications as a starter testsuite for both vendors and users. Vendors get extra testing and some assurance open source projects will work with their hardware. Users of IPMI (including someone like Cyclades) get extra assurance their technology will work with certain hardware. Open source projects get more testing of their tools. Combination of multiple projects covers more IPMI functionality than any one project (can likely) cover on their own. TODOS: Zresearch - Start on FreeIPMI Testsuite LLNL - Get/devel IPMItool testsuite, speak to OpenIPMI author General todo: Try to build momentum on this. IPMItool + Ipmipower: - Idea is HPC features of Ipmipower would be very useful in Ipmitool. Ipmitool would get HPC features and Ipmipower gets more IPMI specification coverage. Interest: Cyclades TODO: Continue discussions on it with Ipmitool author. Just need to start. ICTS Why is the ICTS testsuite only available to IPMI Adopters. This is stupid, users want it too for testing. TODO: Zresearch, LLNL, anyone: Bug Intel people. FreeIPMI in Redhat -- Get vendor support by getting FreeIPMI into RHEL. TODO: LLNL and SLAC will bug Redhat on our weekly conference calls. FreeIPMI TODOS -- Zresearch TODO: Raw Hex command support Zresearch TODO: Perl/Python Bindings(?) (Al: Sorry, my notes weren't clear, I'm not sure.) Zresearch TODO: Adveritse/document Guile, point to howto's, supply templates Web GUI/Windows Compilation of FreeIPMI --- I don't know if we came to a conclusion, I can't remember. Sorry. Maybe vendors can tell us if this is important to them and would make them more interested in FreeIPMI. FreeIPMI Coding --- CVS Tagging: Announce to freeipmi-devel before making a release tag. CVS branching: Branch experimental code and work independently until it is reasonably complete. Then merge into head. Incomplete changes or major architectural changes (i.e. UDM would have fallen under this) aren't submitted into the head until completion. fiid_template_t: We will always stay to spec. Never deviate! fiid_template_t/fiid_obj_t reorganization: We will all think about it and discuss further on the mailing list. There are many different methods to re-architect the underlying objects to meet this need. lan session
Re: [Freeipmi-devel] FIID Re-Implementation
Just a bit of an update so people can make comments on the current
direction:
typedef struct fiid_field
{
uint32_t max_field_len;
char key[FIID_FIELD_MAX];
} fiid_field_t;
typedef fiid_field_t fiid_template_t[];
struct fiid_field_data
{
uint32_t max_field_len;
char key[FIID_FIELD_MAX];
unsigned int field_len;
};
struct fiid_obj
{
uint32_t magic;
uint8_t *data;
unsigned int data_len;
struct fiid_field_data *field_data;
unsigned int field_data_len;
};
int8_t fiid_template_field_lookup (fiid_template_t tmpl, uint8_t *field);
int8_t fiid_obj_field_lookup (fiid_obj_t obj, uint8_t *field);
fiid_obj_t fiid_obj_create (fiid_template_t tmpl);
int8_t fiid_obj_destroy (fiid_obj_t obj);
fiid_obj_t fiid_obj_dup (fiid_obj_t src_obj);
int8_t fiid_obj_clear (fiid_obj_t obj);
int8_t fiid_obj_clear_field (fiid_obj_t obj, uint8_t *field);
int8_t fiid_obj_set (fiid_obj_t obj, uint8_t *field, uint64_t val);
int8_t fiid_obj_get (fiid_obj_t obj, uint8_t *field, uint64_t *val);
int8_t fiid_obj_set_data (fiid_obj_t obj, uint8_t *field, uint8_t *data,
uint32_t data_len);
int8_t fiid_obj_get_data (fiid_obj_t obj, uint8_t *field, uint8_t *data,
uint32_t data_len);
int8_t fiid_obj_set_block (fiid_obj_t obj, uint8_t *field_start, uint8_t
*field_end, uint8_t *data, uint32_t data_len);
int8_t fiid_obj_get_block (fiid_obj_t obj, uint8_t *field_start, uint8_t
*field_end, uint8_t *data, uint32_t data_len);
A few comments:
1) Now that we're moving to abstract away the internal implementation of
fiid obj's, many of the original functions like fiid_obj_field_start()
are static functions and are hidden from the user.
2) I believe the choice to call the early interface functions
fiid_obj_malloc, fiid_obj_free, and fiid_obj_memset, were based
upon the fact that it was known that a fiid_obj_t was a void * pointer.
Now that we have abstracted that away, the function have been renamed
fiid_obj_create, fiid_obj_destroy, and fiid_obj_clear. This is a
semantic issue and I would be willing to change this if people disagree.
3) After a fiid object is created, the templates are never passed around
anymore.
4) I'm going to develop an iterator interface for this API soon too.
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Albert Chu [EMAIL PROTECTED]
Date: Thursday, January 12, 2006 1:45 pm
Subject: Re: [Freeipmi-devel] FIID Re-Implementation
typedef struct fiid_field
{
uint32_t max_field_len;
char key[FIID_FIELD_MAX];
uint8_t requirement_flag;
uint8_t length_flag;
} fiid_field_t;
Hmmm. Thinking about this again. I'm not sure the flags are even
necessary. I believe the 'len' field of a 'struct fiid_setting'
will be
able to take care of both of these issues. If the 'len' written to
thefiid_obj_t is zero, then clearly it is optional or dependent and
shouldn't be sent in the packet. Whatever 'len' it is set to will
clearly determine if it is variable length or not.
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Albert Chu [EMAIL PROTECTED]
Date: Thursday, January 12, 2006 8:45 am
Subject: [Freeipmi-devel] FIID Re-Implementation
Howdy all,
I would like to discuss this topic from the FreeIPMI meeting more
deeply.
I would like to propose we leave my ipmi 2.0 branch
(al_ipmi_2_0_branch)sitting. I think it's best not to merge it
into the head until our
agreed upon objectives for the next generation library are met
for
ipmi1.5 first. I am open to discussion about this too though.
Fiid Re-Architecture:
-
As was discussed at the meeting, there are two major problems now
showing up due to IPMI 2.0, many more optional or dependent
fields exist and many are variable length. Some examples:
- The length of authcode/integrity fields are dependent on the
digest algorithm used.
- OEM fields are sent dependent on if the payload is specifically
citedas a OEM type.
The following is my proposal for the fiid re-architecture. It
attemptsto abstract information far more to deal with the above
issues and
issues with later IPMI versions.
#defines and structure re-definitions
-
#define FIID_FIELD_REQUIRED 0x0
#define FIID_FIELD_OPTIONAL 0x1
#define FIID_FIELD_DEPENDENT0x2
#define FIID_FIELD_FIXED_LENGTH 0x0
#define FIID_FIELD_VARIABLE_LENGTH 0x1
typedef struct fiid_field
{
uint32_t max_field_len;
char key[FIID_FIELD_MAX];
uint8_t requirement_flag;
uint8_t length_flag;
} fiid_field_t;
typedef fiid_field_t const fiid_template_t[];
struct fiid_setting
{
fiid_field_t field;
uint32_t len;
}
struct fiid_obj
{
void
Re: [Freeipmi-devel] warnings patch
Hi Anand, So I can carry things down into my branches, it seems that all the fixes are (uint8_t *) casts on anything that was originally a char * ?? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Avati [EMAIL PROTECTED] Date: Thursday, January 19, 2006 5:41 am Subject: [Freeipmi-devel] warnings patch Hi, fixes about 1041 warnings with gcc4 and a couple with gcc3 regards, avati ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: UDM error codes
If we receive incomplete or corrupted packet, parsing (i.e. lesser or
greater bytes) would lead to memory faults. It is safer to drop the
packet instead.
There is a difference between a corrupted packet and a shortened
packet. Having a packet the expected length of the response is a in
fact a normal condition. For example if you pass a bad username in a get
session challenge packet, the BMC responds with a shortened packet with
a bad comp-code.
I handle this condition in unassemble_ipmi_lan_pkt() and
fiid_obj_dump_lan().
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Anand Babu [EMAIL PROTECTED]
Date: Thursday, February 2, 2006 3:37 pm
Subject: Re: UDM error codes
,[ Albert Chu [EMAIL PROTECTED] ]
| Hi guys,
| Can the UDM-LAN interface return error codes back to the user? As
| far as I can tell, it can't.
|
| In unassemble_ipmi_lan_pkt2() there is:
|
| if (pkt_len != lan_packet_length)
| {
| free (tmpl_lan_packet);
| return (-1);
| }
|
| So if the packet is an incorrect length, an error code won't be
| parsed and returned.
`
If we receive incomplete or corrupted packet, parsing (i.e. lesser or
greater bytes) would lead to memory faults. It is safer to drop the
packet instead.
Currently ipmi_lan_cmd2 checks for or length cases and reports to
STDERR stream to user to report to freeipmi-devel(at)gnu.org mailing
list. unassemble is called only in case of proper length. You may also
notice.
Also look at the recently introduced way to pass error messages.
ipmi_device_t has a field errmsg[IPMI_ERR_STR_MAX_LEN] to hold a
more detailed latest error string. If return codes are -1, high level
calls can use this string, instead of less informative errno.
--
Anand Babu
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
The GNU Operating System [http://www.gnu.org]
Z RESEARCH [http://www.zresearch.com]
A Supercomputing Company.
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] more frequent releases
More people know C, more people know CVS, so more people can help and contribute to FreeIPMI. Fewer people know Scheme, even fewer people know GNU Arch. Its another barrier to entry for people to help. Now that I think about it more. I'm even more against it. Thinking about how often we ask people to get the latest checked in version, most people by default won't have GNU Arch installed on their systems. So it'll be more difficult for them to actually get a recently checked in version. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Thursday, February 2, 2006 4:11 pm Subject: Re: [Freeipmi-devel] more frequent releases Hey AB, Thinking about it a bit, I don't think we should move to GNU Arch. It'sfor the same reason we need to move the Scheme code out of FreeIPMI. More people know C, more people know CVS, so more people can help and contribute to FreeIPMI. Fewer people know Scheme, even fewer people know GNU Arch. Its another barrier to entry for people to help. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Thursday, February 2, 2006 3:39 pm Subject: [Freeipmi-devel] more frequent releases Hi Al, Let us make a 0.2.0 release and move to GNU Arch after that. GNU Arch encourages distributed way of development and branching. Moving forward, we should make our release schedules more aggressive. Once in a month or two. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] Z RESEARCH [http://www.zresearch.com] A Supercomputing Company. ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: lets meet again
Sounds good. I can't do Sunday since it's Superbowl day :-) Otherwise any day. Are you willing to meet today? I think I'll be done with my fiid reimplementation before noon. We could meet at the starbucks again? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Friday, February 3, 2006 2:55 am Subject: lets meet again Hi Albert, Lets meet and re-synchronize again. We have a lot to discuss about the code base now. It has become too difficult to discuss over email. Particularly - * Al's new fiid implementation * UDM layers * IPMI 2.0 LAN driver Any time from starting from Today, Saturday, Sunday or Next week Thursday onwards. I can come over to your place like last time. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] fiid reimplementation notes
With the exception of one SDR bug that's making ipmi-sensors say cat ate teh fish on a corner case, the core work is complete. Its in the branch 'al_fiid_rearchitect_branch'. Notes: 1) Good stuff I remember when re-working code to use the new API assemble/unassemble: Using the new fiid_obj_set_block(), fiid_obj_get_block(), fiid_obj_set_all(), and fiid_obj_get_all() functions, there is no more need to calculate various offsets. The code (to me) looks a lot cleaner than it did before. No more passing around templates: Reduces data to manage. Additional parameter checking: Template information is now stored in the fiid_obj_t, so we now (finally, after me harping about this for probably 2 years :-)) have the ability to ensure that an object passed to a function has the correct length and is the object of the correct type. LAN Session Header: The multiple session header templates (tmpl_hdr_session, tmpl_hdr_session_auth, tmpl_hdr_session_auth_calc) are now just one (tmpl_hdr_session) b/c of optional field support for the auth_code. SDR record lengths: Workarounds are no longer needed to get around the unexpected length of record types using the Get SDR record command. SDR record types: Workarounds are no longer needed to get around the variable length string sensor/device names at the ends of SDR record types. I think there were a few more workarounds that were eliminated b/c of suport for optional/variable length data, but I can't remember them. 2) Not so good stuff I noticed when re-working the code No more alloca: If we want to abstract away the underlying data structures, the casting of fiid_obj_t to uint8_t * has to go away. Longer code: Some code ended up a bit longer. Some longer code was needed b/c of cleanup logic that was needed. Parameter checking made things longer, but it really should have been there from the start. Reserved fields have to be set: With optional fields being supported, reserved fields must be set in fill_* functions. Otherwise the new fiid interface assumes the data isn't set, is optional, and thus shouldn't be stuffed in a packet. 3) TODO stuff I certainly don't know every subsection of the IPMI spec by heart. I may have guessed some fields were required fixed length, when in fact they were optional or variable length. Hopefully anything will come up during additional testing. Some code cleanup is needed to remove duplicate code. Now that templates do not need to be passed around to fiid functions, a lot more duplicate code exists, which can be collapsed into functions. Some code ended up a lot longer b/c earlier code worked off the assumption that fiid_obj_t's were char *buffers. The code logic used from before didn't fit in with the new fiid API too well, so a lot of additional code was added to get around it. Once the code logic is fixed, the code should be clean and happy again. I don't have a machine with PEF, so all of my reimplementation needs to be tested. 4) Maybe todo I'm still debating the naming of a few of the fiid functions. Also, I need to rethink the packet templates formats. The common case is for fields to be a fixed length and required for transmission. So it would be wiser for me to make that the default, and optional or variable length fields the exception. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] sensor type code 12h , offset 05h
Hi Bala, I noticed in ipmi-sensor-event-messages.c that you have code indicating offset 05h for sensor type code 12h (system event). I cannot find offset 05h in the sensor types table or an errata. Is this perhaps a vendor specific offset? Or am I just not looking in the right place in the spec? Thanks, Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] sensor type code 12h , offset 05h
Cool thanks. It's in the IPMI 1.5 spec errata, but not the IPMI 1.5 + 2.0 spec errata. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Bala.A [EMAIL PROTECTED] Date: Wednesday, February 8, 2006 6:25 pm Subject: Re: [Freeipmi-devel] sensor type code 12h , offset 05h Hi Al, Page No. 378 (400 in pdf viewer) in latest IPMI v1.5 spec. Thanks, Bala --- Free as in freedom http://www.gnu.org/ Hi Bala, I noticed in ipmi-sensor-event-messages.c that you have code indicating offset 05h for sensor type code 12h (system event). I cannot find offset 05h in the sensor types table or an errata. Is this perhaps a vendor specific offset? Or am I just not looking in the right place in the spec? Thanks, Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #15689] doc/examples don't build
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15689 Summary: doc/examples don't build Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Thu 02/09/06 at 16:19 Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: The examples should really be part of the default build, so we know that they are fixed at the appropriate times. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=15689 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] code cleanup/auditting for libfreeipmi
I just thought I'd give a heads up about some of the code cleanup/auditing I'm doing for 0.3.0. 1) Some of the fiid templates are inconsistent with each other. I've been personally hit by bugs b/c some templates used user_name as a field name while others used username. I've also seen num vs. number, and addr vs. address. So a number of templates/fields may be changing soon as I try to create consistency through the library. Most of the time, I simply rename fields to exactly what is in the spec. 2) Likewise for function names and template names. For example, fill_hdr_session vs. fill_lan_msg_hdr. fill_hdr_session is now fill_lan_session_hdr. ipmi-sessions.[ch] are now gone too, with code moved into ipmi-lan files. 3) Code ordering. This is just me being anal. But I'm making sure templates, functions, etc. are ordered in the files correctly. It makes it easier for reading the code along with the spec. 4) Of course there is duplicate code, unused code, random crapola that I'm cleaning up / removing along the way. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] code cleanup/auditting for libfreeipmi
So a number of templates/fields may be changing soon as I try to create consistency through the library. Most of the time, I simply rename fields to exactly what is in the spec. Hmmm. This is now turning into don't abbreviate anything. I suppose that's the only way to get consistency. Abbreviating words leads to people abbreviating differently or not at all in various places. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Tuesday, February 14, 2006 2:57 pm Subject: [Freeipmi-devel] code cleanup/auditting for libfreeipmi I just thought I'd give a heads up about some of the code cleanup/auditing I'm doing for 0.3.0. 1) Some of the fiid templates are inconsistent with each other. I've been personally hit by bugs b/c some templates used user_name as a field name while others used username. I've also seen num vs. number, and addr vs. address. So a number of templates/fields may be changing soon as I try to create consistency through the library. Most of the time, I simply rename fields to exactly what is in the spec. 2) Likewise for function names and template names. For example, fill_hdr_session vs. fill_lan_msg_hdr. fill_hdr_session is now fill_lan_session_hdr. ipmi-sessions.[ch] are now gone too, with code moved into ipmi-lan files. 3) Code ordering. This is just me being anal. But I'm making sure templates, functions, etc. are ordered in the files correctly. It makes it easier for reading the code along with the spec. 4) Of course there is duplicate code, unused code, random crapola that I'm cleaning up / removing along the way. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] latest 0.3.0 merged into head
Just some notes: 1) The new fiid is in the head 2) I don't have a machine with acpi, smic, ssif, or pef. So the in-band smic ssif, bmc-config --checkin/checkout for pef, and something that will do an acpi-locate should be tested. 3) there are tons of new -udm files now. Eventually, they will be put into other directories/libs. They're still there now. 4) There's still more to go. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] freebsd sys/time.h
Thanks Dmitry. I'll assume it was a typo then. I'll fix it up. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Dmitry Frolov [EMAIL PROTECTED] Date: Saturday, February 25, 2006 9:01 pm Subject: Re: [Freeipmi-devel] freebsd sys/time.h * Albert Chu [EMAIL PROTECTED] [25.02.2006 14:24]: Hey guys, Noticed the following in freeipmi.h. # if TIME_WITH_SYS_TIME # include sys/time.h # include time.h # else # if HAVE_SYS_TIME_H # include sys/time.h # else # ifdef __FreeBSD__ #include sys/time.h # else #include time.h # endif # endif # endif Can autoconf not find sys/time.h on FreeBSD? Or was the above just a typo/mistake? Don't know the source of this, but configure script found both time.h and sys/time.h here on various FBSD versions: [EMAIL PROTECTED] ttyp0:~/tmp/freeipmi-0.2.0-beta0$ ./configure [...] checking whether time.h and sys/time.h may both be included... yes [...] [EMAIL PROTECTED] ttyp0:~/tmp/freeipmi-0.2.0-beta0$ grep TIME config.h #define TIME_WITH_SYS_TIME 1 wbrw, dmitry. -- Dmitry Frolov [EMAIL PROTECTED] RISS-Telecom Network, Novosibirsk, Russia [EMAIL PROTECTED], +7 3832 NO WA1T, DVF-RIPE ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16094] cannot debug fish commands when LAN is used
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16094 Summary: cannot debug fish commands when LAN is used Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Tue 03/14/06 at 18:04 Category: fish Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: There is no mechanism (that I know of) for a user to debug ipmi-sensors/ipmi-sel/and bmc-config over LAN. So when the command hangs, you just don't know what is the cause is. Al ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16094 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16093] ipmi-sensors help outputs with wrong program name
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16093 Summary: ipmi-sensors help outputs with wrong program name Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Tue 03/14/06 at 18:02 Category: fish Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: /usr/sbin/ipmi-sensors -D=LAN -h ptdev3 -u testadmin -p test Usage: bmc-info [OPTION...] Try `bmc-info --help' or `bmc-info --usage' for more information. same with ipmi-sel and bmc-config ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16093 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [sr #103662] bmc-config should checkout/commit based on number of users
Update of sr #103662 (project freeipmi): Priority: 1 - Later = 5 - Normal Severity:1 - Wish = 3 - Normal Status: Postponed = None ___ Follow-up Comment #3: My understanding is, this command gives details (max_channel_user_ids, current_channel_user_ids and current_channel_fixed_user_names) for a given channel number. By probing the max_channel_user_ids for the LAN and Serial Channels, shouldn't we get the maximum number of possible users the BMC can support? Even if this isn't the case, one can loop w/ increasing user_ids until a simple IPMI command such as Get User Name fails. Al ___ Reply to this item at: http://savannah.gnu.org/support/?func=detailitemitem_id=103662 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: symbols missing problem
Hey Rene, Yup, I was able to verify that rebuilding the rpm under Suse fixed the problem. I'm not really sure what the problem was with the old Redhat RPMS. Just did the typical: rpmbuild --rebuild freeipmi-0.2.0-1.src.rpm If you have a number of architectures of Suse, it'd be great if you could rebuild the rpms and we could stick em all on the website. 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 3:05 pm Subject: Re: symbols missing problem Hi, Just finished installing libtool, autoconf, and automake. So I take it I would have been better off installing from source rather that using the RPMs. I take it they are RedHat based and since I am running SuSE it didn't quite work :-) thanks again Rene Anand Babu wrote: ,[ Albert Chu [EMAIL PROTECTED] ] | Are you running autogen.sh on the IBM? With some other projects, I a | recall Suse problems with autoconf/automake. I fixed the problem by | running ./autogen.sh on a Redhat/Fedora/Debian system. ` Al, I think you are right. This is caused because of not-running-autogen.sh. When I run the binary's in place from the source tree (they are actually libtool scripts) they work OK. Only on install they screw up. This must be caused because of configure script produced from a different platform. Rene, Can you please install libtool, autoconf and automake on your system, So that I can run autogen.sh? -- - -- Rene Salmon Tulane University Center for Computational Science Richardson Building 310 New Orleans, LA 70118 http://www.ccs.tulane.edu Tel 504-862-8393 Fax 504-862-8392 ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16198] website links broken
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16198 Summary: website links broken Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Mon 03/27/06 at 09:49 Category: Documentation Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: referring to the ones here http://www.gnu.org/software/freeipmi/download.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16198 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: [Freeipmi-users] ipmi_open_inband no such device on Ibm e325
Second thing I may try is to increase the value of
libfreeipmi/src/ipmi-kcs-api.c:IPMI_KCS_SLEEP_USECS to something
higher. Because MSI's BMC is slow in I/O.
Why don't we make it a command-line option for all in-band tools?
Al
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
- Original Message -
From: Anand Babu [EMAIL PROTECTED]
Date: Sunday, April 2, 2006 10:54 pm
Subject: Re: [Freeipmi-devel] Re: [Freeipmi-users] ipmi_open_inband no
such device on Ibm e325
,[ Albert Chu [EMAIL PROTECTED] ]
| 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.
`
Hi Rene, I got time to work on this only now. I think you have changed
the pass code.
OpenBSD guys got inband driver to work on IBM e325. This looks like a
BMC firmware bug. Refer to
http://undeadly.org/cgi?action=articlesid=20060105200847
Can you please try no-probing option. This will force the KCS driver
to use successive reg-spacing (=1byte) and I/O mapped access.
# bmc-info --no-probing
Second thing I may try is to increase the value of
libfreeipmi/src/ipmi-kcs-api.c:IPMI_KCS_SLEEP_USECS to something
higher. Because MSI's BMC is slow in I/O.
We may also need SDR firmware fixes. I will tell you what you need to
report to IBM once we get the basic stuff to work.
--
Anand Babu
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
The GNU Operating System [http://www.gnu.org]
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] IBM e325 and GNU FreeIPMI
A.B., Was your fix to manually code the io-port address, register spacing, etc. into bmc-info to get around the SMBIOS broken-ness? If that's the case, then we should add options to bmc-info and all the inband tools to allow the user to manually set them on the command line (or via config file) if the firmware is bad. Otherwise how will any user with bad firmware ever use FreeIPMI? Especially if IBM never releases a fix (they may not be obligated to). Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Monday, April 3, 2006 7:48 am Subject: [Freeipmi-devel] IBM e325 and GNU FreeIPMI IBM e325 BMC firmware has lots of bugs. I got bmc-info to work inband. SMBIOS reports that BMC is memory mapped, but it is really io ports based. I also found that GNU FreeIPMI was checking for SMBIOS record length to be 16 bytes which should be = 16 bytes. You should also unload OpenIPMI kernel modules before running GNU FreeIPMI tools. (lsmod | grep ipmi and rmmod all of them). Rest of the tools are waiting for data from BMC indefinitely in the middle of I/O. I tried fiddling with poll interval. but no luck. Proper fix should come from IBM. Best approach for now is to use GNU FreeIPMI in out-of-band mode. - athena /root# bmc-info Device ID: 0 Device Revision: 1 Firmware Revision: 1.72 [Device Available (normal operation)] IPMI Version: 1.5 Additional Device Support: [Sensor Device] [SDR Repository Device] [SEL Device] [FRU Inventory Device] [IPMB Event Receiver] [Bridge] [Chassis Device] Manufacturer ID: 2h Product ID:8835h Aux Firmware Revision Info: 0h Channel Information: Channel No: 0 Medium Type: IPMB (I2C) Protocol Type: IPMB-1.0 Channel No: 1 Medium Type: 802.3 LAN Protocol Type: IPMB-1.0 -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] IBM e325 and GNU FreeIPMI
And I'll add that we can easily document these workarounds into the manpages/docs. Please see how I did the ipmipower manpage for all the non-compliant vendors I've found. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Monday, April 3, 2006 5:39 pm Subject: Re: [Freeipmi-devel] IBM e325 and GNU FreeIPMI A.B., Was your fix to manually code the io-port address, register spacing, etc. into bmc-info to get around the SMBIOS broken-ness? If that's thecase, then we should add options to bmc-info and all the inband tools to allow the user to manually set them on the command line (or via config file) if the firmware is bad. Otherwise how will any user with bad firmware ever use FreeIPMI? Especially if IBM never releases a fix (they may not be obligated to). Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Monday, April 3, 2006 7:48 am Subject: [Freeipmi-devel] IBM e325 and GNU FreeIPMI IBM e325 BMC firmware has lots of bugs. I got bmc-info to work inband. SMBIOS reports that BMC is memory mapped, but it is really io ports based. I also found that GNU FreeIPMI was checking for SMBIOS record length to be 16 bytes which should be = 16 bytes. You should also unload OpenIPMI kernel modules before running GNU FreeIPMI tools. (lsmod | grep ipmi and rmmod all of them). Rest of the tools are waiting for data from BMC indefinitely in the middle of I/O. I tried fiddling with poll interval. but no luck. Proper fix should come from IBM. Best approach for now is to use GNU FreeIPMI in out-of-band mode. - athena /root# bmc-info Device ID: 0 Device Revision: 1 Firmware Revision: 1.72 [Device Available (normal operation)] IPMI Version: 1.5 Additional Device Support: [Sensor Device] [SDR Repository Device] [SEL Device] [FRU Inventory Device] [IPMB Event Receiver] [Bridge] [Chassis Device] Manufacturer ID: 2h Product ID:8835h Aux Firmware Revision Info: 0h Channel Information: Channel No: 0 Medium Type: IPMB (I2C) Protocol Type: IPMB-1.0 Channel No: 1 Medium Type: 802.3 LAN Protocol Type: IPMB-1.0 -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] [bug #16259] --no-probing broken
I got it. Mistake due to API changes. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Monday, April 3, 2006 6:44 pm Subject: [Freeipmi-devel] [bug #16259] --no-probing broken URL: target=lhttp://savannah.gnu.org/bugs/?func=detailitemitem_id=16259 Summary: --no-probing broken Project: GNU FreeIPMI Submitted by: ab Submitted on: Monday 04/03/06 at 18:44 Category: fish Severity: 4 - Important Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: balamurugan Open/Closed: Open ___ Details: --no-probing is broken for all tools. ___ Reply to this item at: target=lhttp://savannah.gnu.org/bugs/?func=detailitemitem_id=16259 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16259] --no-probing broken
Update of bug #16259 (project freeipmi): Open/Closed:Open = Closed ___ Follow-up Comment #1: fixed logic bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16259 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] 0.2.1 development patch
Ok. Well, I still think we should add the note to all in-band tools. So that users atleast know where to be pointed to. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Anand Babu [EMAIL PROTECTED] Date: Tuesday, April 4, 2006 4:46 pm Subject: Re: [Freeipmi-devel] 0.2.1 development patch Albert Chu wrote: You know right, On IBM e325, only ipmi-locate and bmc-info works inband.BMC doesn't respond properly for other commands. bmc-config works out of band, so it's not an ipmi compliance issue with the bmc commands. If it can't work in-band w/ --noprobing, then wouldn't it be a probing/locate issue in the fish code? Problem is in crappy KCS controller. bmc-info when forced to work on IO-MAPPED KCS interface, it works OK. Rest of the tools don't. Because get_device_info is a simple IPMI command with no much data. bmc-config starts to fetch data and hangs in the middle. It may be possible to tweak the KCS driver to work for this BMC, But I don't have access to e325 any more. -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16270] udm - out of band hangs on lost packets
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16270 Summary: udm - out of band hangs on lost packets Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Wednesday 04/05/06 at 09:49 Category: fish Severity: 3 - Normal Item Group: Improper Behaviour Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: packets need to be retransmitted or timeout w/ error to user ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16270 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16271] on ipmi error close session
Update of bug #16271 (project freeipmi): Open/Closed:Open = Closed ___ Follow-up Comment #1: maybe not a bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16271 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16283] udm-raw interface should be passed lun netfn as parameters, not in the buffer
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16283 Summary: udm-raw interface should be passed lun netfn as parameters, not in the buffer Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Thursday 04/06/06 at 08:53 Category: libfreeipmi Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: the current udm interface assumes the lun netfn is the first byte of the buffer, which doesn't make any sense. UDM is suppose to abstract the header information. And the raw interface is supposed to allow the user to supply any buffer for the 'payload' of the ipmi command. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16283 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16291] in-band --driver-address option should take hex input
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16291 Summary: in-band --driver-address option should take hex input Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Thursday 04/06/06 at 16:10 Category: fish Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: i.e. --driver-address=0xCA2 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16291 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16292] ibm e325 workaround documention needed for 0.3.0
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16292 Summary: ibm e325 workaround documention needed for 0.3.0 Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Thursday 04/06/06 at 16:16 Category: Documentation Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16292 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16292] ibm e325 workaround documention needed for 0.3.0
Follow-up Comment #1, bug #16292 (project freeipmi): and info/web docs ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16292 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #16293] privilege minimums should be stated in manpages
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16293 Summary: privilege minimums should be stated in manpages Project: GNU FreeIPMI Submitted by: chu11 Submitted on: Thursday 04/06/06 at 16:35 Category: Documentation Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: bmc-config is the one that mostly needs it ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16293 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] bmc-config ipmi 2.0 problem
B) Configuration options 'Password16' or 'Password20' will be used. - Resulting issue: Both can't be output to the user, the user will simply have to know that one or the other can be used. Also, there is no method by which to propogate back up to bmc-config which key to output during a --checkout. After some thinking, I think Password and Password20 are the options I'll go with. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Albert Chu [EMAIL PROTECTED] Date: Tuesday, April 11, 2006 2:55 pm Subject: [Freeipmi-devel] bmc-config ipmi 2.0 problem Looking for suggestions/recommendations: Background: In ipmi 1.5, the max password length is 16 bytes. In ipmi 2.0, passwords can be set to a max of 16 bytes or 20 bytes. Internally in the firmware, passwords are padded up to the max and a flag indicates if the max is 16 bytes or 20 bytes. If the max is 20 bytes, only ipmi 2.0 can be used to establish an ipmi session. If the max is 16 bytes, ipmi 1.5 or ipmi 2.0 can be used to establish an ipmi session. Problem: Assuming the user is on an IPMI 2.0 machine, if the user inputs a password 16 bytes to bmc-config, how should the user indicate which max password length should be configured? A) A new flag Max_Password_Length in the config file indicates if themax password length is 16 or 20 bytes. - Resulting issue: bmc-config assumes each config file line has a configurable option. Now two lines in the config file equal one configurable value. Bmc-config would probably need to be re- architectedto handle this. B) Configuration options 'Password16' or 'Password20' will be used. - Resulting issue: Both can't be output to the user, the user will simply have to know that one or the other can be used. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] GUILE 1.8 build problem!
Hi, So we know, what version of FreeIPMI was this. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Harshavardhana Ranganath [EMAIL PROTECTED] Date: Friday, April 28, 2006 12:43 pm Subject: [Freeipmi-devel] GUILE 1.8 build problem! ===File ~/Mail/freeipmi-devel=== i was trying out building freeipmi on guile-1.8 running system. there were problem's in configure.ac normally in configure.ac for guile-1.6.x gh_enter works for the configuration under AC_CHECK_LIBS, but with guile-1.8 gh_enter and even scm_boot_guile didn't work. i have tried it on freetalk and commited too, coz the gh_* being deprecated features for upcoming guile releases. Alas! didn't work again. Does anybody encountered it or anybody tried building freeipmi on guile-1.8 configured system??. Regards Harshavardhana ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] freeipmi-0.2.1 fails on SE7210 using FreeBSD 6.0
Hi Gernot, Do you know if 0.2.0 worked? Or hopefully atleast 0.1.3? I'm wondering what could have been messed up along the way. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory - Original Message - From: Gernot Hueber [EMAIL PROTECTED] Date: Tuesday, May 2, 2006 7:10 am Subject: [Freeipmi-devel] freeipmi-0.2.1 fails on SE7210 using FreeBSD 6.0 Hi, I have patched the 0.2.1 version for FreeBSD 6.0, well it works fine on older Intel server boards. Actually it fails on the SE7210TP1-E. Maybe due to SSIF? ipmi-locate returns FAILED only. Clearly, there is no mechanism for freeipmi to get the info from. Can anybody provide some information on this issue - perhaps a solution ;-) Regards Gernot # ipmi-locate --version IPMI Locate [ipmi-locate-0.2.1] Copyright (C) 2003-2005 FreeIPMI Core Team This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. #ipmi-locate 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 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 # sel --: --: --: --: ~ ~ Cat ate the fish!! ~ ~ --: --: --: --: Fish Exception Handler: tag: out-of-range throw args : (list-ref Argument ~S out of range: ~S (2 9) #f) data : [/usr/local/sbin/sel] No backtrace available. # sensors --: --: --: --: ~ ~ Cat ate the fish!! ~ ~ --: --: --: --: Fish Exception Handler: tag: out-of-range throw args : (list-ref Argument ~S out of range: ~S (2 9) #f) data : [/usr/local/sbin/sensors] No backtrace available. -- DI Gernot Hueber Institut für Integrierte Schaltungen Altenbergerstr. 69 4040 Linz Tel +43 732 2468 7120 Fax +43 732 2468 7126 Email [EMAIL PROTECTED] Web www.riic.at ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Avati's contributions
Please check with Jim too. Don't know if Ian is listening. 3 out of 5 core-team votes will do. You can add him. Happy Hacking, -- Anand Babu GPG Key ID: 0x62E15A31 Blog [http://ab.freeshell.org] The GNU Operating System [http://www.gnu.org] Z RESEARCH [http://www.zresearch.com] A Supercomputing Company. -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] removed ipmi_locate_defaults_get_dev_info() in things_to_try list
I would like to add --defaults option to ipmi-locate and the tool will display default values when this option is passed. Just let me know your thoughts. That sounds good. Al Thanks, Bala --- Free as in freedom http://www.gnu.org/ Hi Bala, To me, it makes sense to remove 'defaults' from the tool ipmi-locate. But for library probing, I feel it must still be there. If there manufacturer offers no inband information for IPMI (through smbios, dmi, or pci), then at the bare minimum you can try the IPMI defaults. If you don't assume the IPMI defaults, then do you assume the user must also input the address/registerspacing/etc. into the inband tools? Otherwise probing will always fail. I've reverted this change, because I have a machine which has no probing information. It simply implements the IPMI defaults. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] bmc-config pef checkout
Out of my curiosity, has this been verified to work on a machine? I have three IPMI machines, all of which see completion code errors of 0xC1 = Used to indicate an unrecognized or unsupported command. I can't help but think that atleast 1 of my 3 should support PEF. So maybe something is wrong with the code? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] bmc-config: PEF config checkout
Hi Ingo, Thanks Ingo. Great catches. I've checked all your changes in. Al Ingo van Lil [EMAIL PROTECTED] schrieb: A patch for libfreeipmi is attached. Admittedly, checking out the PEF section isn't any more successful with the patch than it used to be, but at least the error message changed from unsupported command to expression failed. OK, got it: The parameter revision field was missing in all the tmpl_cmd_get_pef_configuration_parameters_*_rs definitions in ipmi-pef-and-alerting-cmds.c. Patch attached. Cheers, Ingo ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] bmc-info re-architect - please carry over to other tools
Howdy everyone, I committed code to re-architect bmc-info. Please ensure that this re-architecture is carried into atleast the new tools (ipmi-pef, ipmi-chassis, etc.) and when you have time, try to carry them over to ipmi-sel, ipmi-sensors, etc. I will work on the other tools when I have time as well. They are for later hostrange support in the tools. In particular, the re-architecture requires: A) Removing all globals and putting any program information into a structure that can be passed around to all functions doing the core grunt work of the tool. This sets up thread safety for later. B) Move all core code out of main(). Create a function that can be called by main() to do the entire body of work for the tool. This function should be passed the program structure from 'A'. The function should return the exit code it would like main to exit with. This re-architecture sets up the pthread_create() call for later. C) Remove all exit() calls in the core code and ensure the only time the program exits is in main. Errors should be handled by return -1 or NULL etc. and propagated back into the function created by 'B', of which the function in 'B' can decide what the exit code for the program should be. This prevents early termination based on errors and ensures the correct exit code for each thread can be carried until the end. Please see the changes to bmc-info and you'll see what I mean. Thanks, Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] 2/18 change - configure.ac: fix of automake init
What was the error? We should work on an alternate solution rather than just revert to the earlier configure.ac. Al Hi Al, ./autogen.sh failed with your chance. I use autoconf 2.61 automake 1.8.5 Thanks, Regards, Bala --- Free as in freedom http://www.gnu.org/ Bala, Is there a reason you reverted my fix to configure.ac from 2/16/07? Do you guys run an older autoconf version that didn't support the changes I made? I'm confused. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Patch for hex k_g keys in ipmipower, take 2
Hey Levi, Oh, and I think I fixed that 20 byte k_g corner case you mentioned earlier. It's in the stable 0.3.X branch. Al Hey Levi, Looks good. I fixed the one or two remaining nit picks I found. It's now in the 0.3.X stable line and CVS head. Were you going to work on the ipmiconsole and bmc-config equivalent support too? Thanks, Al On Thu, 2007-04-26 at 22:47 -0700, Albert Chu wrote: Hey Levi, Looks pretty good. Some minor nit-picks. Fixed those, and I prevented printing out a key starting with a literal '0x' in ascii. --Levi -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] docs/ directory
1) freeipmi.texi, version-doc.texi, authors.texi, gpl.texi, fdl.texi Most of this doc is just cut and pasted from the manpages and other .txt files, it's already grown out of date, and nobody bothers to keep up with it. I figure someone will get mad at me if I remove the above. But I went ahead and got rid of the rest of it. Some of it looks like it maybe belongs on the webpage along with other presentations. Al 2) freeipmi-hackers-intro.odp seems to be a presentation from 3 years ago? 3) ipmi-over-ts2000.texi why is this here? What does this have to do w/ FreeIPMI? 4) ipmi-network-layout.fig, ipmi-network-layout.xcf for the presentation from 3 years ago? 5) BUGS leftover from 0.1.0?? The only thing we seem to semi-keep up with is the FAQ, b/c we actually modify that and stick it on the webpage from time to time. If I don't hear from anyone I'll assume I can start cleaning up. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Patch for hex k_g keys in ipmiconsole and bmc-config + bugfix
Hey Levi, I've commited the bmc-config strdup fix and bmc-config 0x support into the CVS head and 0.3.X branch. The ipmiconsole part is fine, except for the part that you assume the k_g input into libipmiconsole is 20 bytes. I can understand that you didn't want to change the API format, but I think it'll just have to change. I'll figure out how to adjust it sometime tomorrow. Thanks, Al This patch includes the changes to both ipmiconsole and bmc-config, including a bugfix in bmc-config to fix a memory bug due to a missing strdup. I also noticed that several of the bmc-config sections return non-fatal error codes; I'm assuming that this means there were configuration items within that didn't exist on the BMC. Is this correct? --Levi ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Patch for hex k_g keys in ipmiconsole and bmc-config + bugfix
I added a k_g_len component to workaround the issue. The patch is in the head and 0.3.X branch now. I also found a ipmiconsole state machine bug along the way too. Thanks, Al Hey Levi, I've commited the bmc-config strdup fix and bmc-config 0x support into the CVS head and 0.3.X branch. The ipmiconsole part is fine, except for the part that you assume the k_g input into libipmiconsole is 20 bytes. I can understand that you didn't want to change the API format, but I think it'll just have to change. I'll figure out how to adjust it sometime tomorrow. Thanks, Al This patch includes the changes to both ipmiconsole and bmc-config, including a bugfix in bmc-config to fix a memory bug due to a missing strdup. I also noticed that several of the bmc-config sections return non-fatal error codes; I'm assuming that this means there were configuration items within that didn't exist on the BMC. Is this correct? --Levi ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 0.3.3 release ready?
We've got ourselves a nice chunk of bug fixes. Shall we release 0.3.3? Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] sorry for all the bug spam
buglist hadn't been cleaned up in probably 10-12 months or so. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] use threadsafe functions
Hi everyone, For those hacking on the freeipmi CVS head, please use the thread-safe functions like gethostbyname_r and localtime_r for now on. Most of the tools use threads for the parallel stdout output. I recently caught a few non-thread safe things lingering around from 0.3.0 days. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Bug report version 0.4.3
Hey Manu,
Yep only on ipmi-fru manpage
My cpp/gcc version is 3.3.5.
I think that's definitely old enough to have the parse issue. It is funny
that this one only occurred on ipmi-fru. Others reported occuring in
other manpages.
Hopefully it wasn't too painful to deal with.
Al
Inline
On Tue, 18 Sep 2007, Al Chu wrote:
Hey Manu,
Thanks for the info.
On Tue, 2007-09-18 at 18:14 -0400, Manu Sharma wrote:
I noticed two issues with FreeIPMI version 0.4.3
{1}
Build Error.
I had to place end quotes in the file ipmi-fru.8.pre on lines 1 thru
26 when i used make install option.
Another user reported a similar issue. Some pre-processing wasn't
handled properly on older systems. Wasn't quite of the best way to work
around this besides some flat out removal of text that confused older
preprocessors.
Did this only occur for your on the ipmi-fru manpage?
Yep only on ipmi-fru manpage
My cpp/gcc version is 3.3.5.
{2}
Man Page Error
Man page for Pef-config had the following confusing information for -i
option
-i, --info
Show PEF information
and
-i, --commit
Update configuration information to BMC.
Ahh, thanks for the catch.
Al
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
--
Albert Chu
[EMAIL PROTECTED]
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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 [EMAIL PROTECTED] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] 0.5.0.beta1 FreeBSD 5.x compatibility patch
Cool, thanks. Its in. Al Little patch needed to compile on FreeBSD 5.x releases. Spotted by Sharad Chandra. Index: ipmiconsole/src/libipmiconsole/ipmiconsole_ctx.c === RCS file: /sources/freeipmi/freeipmi/ipmiconsole/src/libipmiconsole/ipmiconsole_ctx.c,v retrieving revision 1.24 diff -u -d -p -r1.24 ipmiconsole_ctx.c --- ipmiconsole/src/libipmiconsole/ipmiconsole_ctx.c 18 Oct 2007 16:18:46 - 1.24 +++ ipmiconsole/src/libipmiconsole/ipmiconsole_ctx.c 24 Nov 2007 06:26:36 - @@ -71,6 +71,7 @@ #include ipmiconsole_debug.h #include ipmiconsole_fiid_wrappers.h #include ipmiconsole_util.h +#include freeipmi-portability.h #define GETHOSTBYNAME_AUX_BUFLEN 1024 ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] 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-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #24300] ipmiconsole cannot connect to various Intel servers
Update of bug #24300 (project freeipmi): Status:None = Fixed Assigned to:None = chu11 Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?24300 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [bug #24300] ipmiconsole cannot connect to various Intel servers
Follow-up Comment #7, bug #24300 (project freeipmi): Sorry, never documented that I fixed them. I think we dealt with it in e-mail. It was fixed in the 0.7.4 release. 0.7.4 - 12/15/08 snip o Fix Intel IPMI 2.0 workarounds in all tools/libraries. snip ___ Reply to this item at: http://savannah.gnu.org/bugs/?24300 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] [sr #105351] Does anyone accomplish the work of run FreeIPMI on cygwin?
Update of sr #105351 (project freeipmi): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/support/?105351 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Dave,
On Mon, 2010-06-21 at 15:57 -0700, Dave Love wrote:
[Sorry, I thought I sent this earlier, but I'm harassed and losing
track.]
Al Chu ch...@llnl.gov writes:
--- bmc-watchdog.c 16 Jun 2010 17:52:38 - 1.131
+++ bmc-watchdog.c 17 Jun 2010 23:18:57 -
@@ -1920,6 +1920,8 @@ _daemon_cmd (void)
reset_period (retry_wait_time * retry_attempt))
retry_attempt = reset_period/retry_wait_time;
+ sleep (5);
+
while (shutdown_flag)
{
struct timeval start_tv, end_tv;
That seemed to work on x4500/Solaris, but then I tried with a shorter
sleep, and now it's not working after restoring the sleep (5), but does
last a longer, variable, time than without the sleep. I'll see if I can
figure any more out.
It does seem to work on an x4100 (not M2) with RedHat.
Just want to clarify, you're saying this sleep(5) makes it work on the
4100?
Al
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] ipmiconsole on FreeBSD
Hi Sean,
On Thu, 2010-06-24 at 09:59 -0700, Sean Bruno wrote:
Just installed freeipmi via ports today (compiled on a FreeBSD 7 box)
and when trying to invoke ipmiconsole was presented with the following
error:
[sean...@x34 ~]$ sudo /usr/local/sbin/ipmiconsole -h 10.73.149.134
--debug
(ipmiconsole_engine.c, ipmiconsole_engine_thread_create, 1121):
pthread_mutex_unlock: Operation not permitted
ipmiconsole_setup: Bad file descriptor
Ick.
Ick indeed. Of all the porting issues I could have imaged, this would
have not been expected. On Linux, the manpage shows
The pthread_mutex_unlock() function may fail if:
EPERM The current thread does not own the mutex.
Some googling suggests its the same on FreeBSD. From the line numbers,
it appears you're using a much older version of FreeIPMI. The newest
version is 0.8.7, but you appear to be using something in the 0.7.X
timeframe. Here's the code.
int
ipmiconsole_engine_thread_create(void)
{
pthread_t thread;
pthread_attr_t attr;
unsigned int *index = NULL;
int perr, rv = -1;
assert(console_engine_is_setup);
if ((perr = pthread_mutex_lock(console_engine_thread_count_mutex)))
{
IPMICONSOLE_DEBUG((pthread_mutex_lock: %s, strerror(perr)));
errno = perr;
return -1;
}
assert(console_engine_thread_count IPMICONSOLE_THREAD_COUNT_MAX);
if ((perr = pthread_mutex_unlock(console_engine_thread_count_mutex)))
{
IPMICONSOLE_DEBUG((pthread_mutex_unlock: %s, strerror(perr)));
errno = perr;
goto cleanup;
}
if ((perr = pthread_attr_init(attr)))
{
IPMICONSOLE_DEBUG((pthread_attr_init: %s, strerror(perr)));
errno = perr;
goto cleanup;
}
if ((perr = pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED)))
{
IPMICONSOLE_DEBUG((pthread_attr_setdetachstate: %s, strerror(perr)));
errno = perr;
goto cleanup;
}
if (!(index = (unsigned int *)malloc(sizeof(unsigned int
{
IPMICONSOLE_DEBUG((malloc: %s, strerror(errno)));
goto cleanup;
}
*index = console_engine_thread_count;
if ((perr = pthread_create(thread, attr, _ipmiconsole_engine, index)))
{
IPMICONSOLE_DEBUG((pthread_create: %s, strerror(perr)));
errno = perr;
goto cleanup;
}
/* Who cares if this fails */
if ((perr = pthread_attr_destroy(attr)))
IPMICONSOLE_DEBUG((pthread_attr_destroy: %s, strerror(perr)));
console_engine_thread_count++;
rv = 0;
cleanup:
if ((perr = pthread_mutex_unlock(console_engine_thread_count_mutex)))
{
IPMICONSOLE_DEBUG((pthread_mutex_unlock: %s, strerror(perr)));
errno = perr;
return -1;
}
return rv;
}
I'm somewhat at a loss. The lock up above clearly succeeded, so I'm not
sure how this error is happening. Also, I know others have run this on
BSD without problems.
This is called via ipmiconsole_engine_init(), which isn't even at a
multi-threaded point. That begs the question, should I not even have the
mutexes there? Maybe they're not necessary. I actually see a few
points in the code maybe they could be removed. Regardless, the error
shouldn't be happening. Do you want to try and remove the lock and the
unlock in the above function
(ipmiconsole/src/libipmiconsole/ipmiconsole_engine.c) and see if that
fixes the problem? PLMK if you'd like to try a patch.
I'm CCing Dmitry, FreeIPMI's resident BSD expert incase he knows
something I don't. Perhaps there is something special about FreeBSD
pthreads that I don't know.
Al
Sean
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Dave, Ok. I'll put a sleep(5) like workaround-addition into bmc-watchdog. Al On Mon, 2010-06-28 at 08:06 -0700, Dave Love wrote: I thought I'd replied to this before... Albert Chu ch...@llnl.gov writes: Just want to clarify, you're saying this sleep(5) makes it work on the 4100? Yes, to the limited extent I tested it, as I'm not interested in running it on x4100. However, it seemed to be running on the x4500 initially, with a similar ILOM version, so I wonder if it's reliable. I haven't had a chance to me around any more with it on the x4500, unfortunately. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Another FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Dave, Frank,
As discussed in the previous thread, there was a corner case in the
bmc-watchdog workaround I previously did. I then discovered another
corner case w/ the workaround.
There is a new beta here.
http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.8.beta1.tar.gz
If you could try it out to make sure I didn't screw anything up, I'd
appreciate it. The core of the new patch is:
diff -p -u -r1.131 bmc-watchdog.c
--- bmc-watchdog/src/bmc-watchdog.c 16 Jun 2010 17:52:38 - 1.131
+++ bmc-watchdog/src/bmc-watchdog.c 28 Jun 2010 18:30:58 -
@@ -1920,6 +1920,21 @@ _daemon_cmd (void)
reset_period (retry_wait_time * retry_attempt))
retry_attempt = reset_period/retry_wait_time;
+ /* IPMI Workaround
+ *
+ * Discovered on Sun x4100M2 and x4200M2
+ *
+ * If implementing the IGNORE_STATE_FLAG workaround flag below, we
+ * need to sleep a little bit to make sure the BMC timer has really
+ * started.
+ *
+ * From 27.7 Internal delays in the BMC may require software to
+ * delay up to 100 ms before seeing the countdown value change and
+ * be reflected in teh Get Watchdog Timer command.
+ */
+ if (cmd_args.common.tool_specific_workaround_flags
IPMI_TOOL_SPECIFIC_WORKAROUND_FLAGS_IGNORE_STATE_FLAG)
+_sleep (1);
+
while (shutdown_flag)
{
struct timeval start_tv, end_tv;
@@ -1984,6 +1999,45 @@ _daemon_cmd (void)
goto sleep_now;
}
+ /* IPMI Workaround
+ *
+ * Discovered on Sun x4100M2 and x4200M2
+ *
+ * If implementing the IGNORE_STATE_FLAG workaround flag above,
+ * we need to reset the previous_present_countdown_seconds to
+ * what it is after the timer reset.
+ *
+ * From 27.7 Internal delays in the BMC may require software to
+ * delay up to 100 ms before seeing the countdown value change and
+ * be reflected in teh Get Watchdog Timer command.
+ */
+ if (cmd_args.common.tool_specific_workaround_flags
IPMI_TOOL_SPECIFIC_WORKAROUND_FLAGS_IGNORE_STATE_FLAG)
+{
+ _sleep (1);
+
+ if ((ret = _get_watchdog_timer_cmd (retry_wait_time,
+ retry_attempt,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ present_countdown_seconds)))
+{
+ _daemon_cmd_error_noexit (Get Watchdog Timer, ret);
+ goto sleep_now;
+}
+
+ previous_present_countdown_seconds = present_countdown_seconds;
+}
+
sleep_now:
if (gettimeofday (end_tv, NULL) 0)
{
Al
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: Another FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Frank, This is indeed very strange. I assume the reboots are because the timer eventually times out, perhaps because the resets are no longer working (lets say the BMC goes out to lunch). Does the bmc-watchdog log say anything interesting? Normally it's /var/log/freeipmi/bmc-watchdog.log. Al On Mon, 2010-07-05 at 23:36 -0700, Frank Steiner wrote: Frank Steiner wrote 2) The really bad thing was three of the X4100M2 being rebooted by the watchdog as reaction to a bmc-watchdog -s -k call I guess. The timer runs 15 minutes and I reset the watchdog by to independent instances every 3 minutes. On all three machines I found this in the logs: Running some tests I can say for sure that the x4100M2 ILOMs are really really bad :-( When running a while-true loop for bmc-watchdog -s -k, the x4100M2 will shutdown after at latest 2 hours and stay powered-off. When running the loop with bmc-watchdog -r it takes 5-6 hours but then the machine is powered off, too. Kind of strange watchdog that can shutdown the machine when you reset it :-( Another thing for Sun to fix... cu, Frank -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: Another FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Frank, That is really random stuff. I am usually always willing to point the finger to myself and say bug in FreeIPMI, but this is way too random. The data not available errors in the log indicate that the packets returned from the BMC are actually malformed. On the flip side, I've personally never tested on Solaris. So who knows if the /dev/bmc was really programmed correctly. I may have screwed up. Is this only happening on one motherboard? I have this feeling that maybe the board is just busted. Al On Tue, 2010-07-06 at 23:52 -0700, Frank Steiner wrote: Albert Chu wrote Hey Frank, This is indeed very strange. I assume the reboots are because the timer eventually times out, perhaps because the resets are no longer working (lets say the BMC goes out to lunch). I don't think so because in the tests I repeat the resets every second and I always see if they succeed or not. Many of them are rejected with some kind of error messages, but it never happens that all fail for more than one minute. However, when I loop bmc-watchdog -g I get the strangest results with all fields showing complete nonsense, like Initial Countdown: 6553 sec Present Countdown: 0 sec and a second later Initial Countdown: 900 sec Present Countdown: 24513 sec and so on. Also the action field etc. change their values. If the timer would just run down, the host would reset and not power-off. So I guess that the ILOM is just that buggy that it can get confused by polling or resetting it :-( Does the bmc-watchdog log say anything interesting? Normally it's /var/log/freeipmi/bmc-watchdog.log. It says a lot, but nothing different just before shutting down that it hadn't showed before. E.g.: [Jul 05 08:38:08]: _set_watchdog_timer_cmd: fill_cmd_set_watchdog_timer: Invalid argument [Jul 05 08:38:18]: Get Cmd: ipmi_kcs_cmd: driver timeout [Jul 05 08:38:22]: Get Cmd: cmd error: 2h [Jul 05 08:38:38]: _get_watchdog_timer_cmd: fiid_obj_get: 'timeout_action': data not available [Jul 05 08:38:38]: _set_watchdog_timer_cmd: fill_cmd_set_watchdog_timer: Invalid argument [Jul 05 08:38:44]: Set Cmd: ipmi_kcs_cmd: driver timeout [Jul 05 08:38:50]: Set Cmd: ipmi_kcs_cmd: internal IPMI error [Jul 05 08:39:01]: Set Cmd: ipmi_kcs_cmd: internal IPMI error [Jul 05 08:39:23]: _get_watchdog_timer_cmd: fiid_obj_get: 'timeout_action': data not available [Jul 05 08:39:27]: _get_watchdog_timer_cmd: fiid_obj_get: 'initial_countdown_value': data not available [Jul 05 08:39:35]: _get_watchdog_timer_cmd: fiid_obj_get: 'initial_countdown_value': data not available [Jul 05 08:39:51]: Get Cmd: cmd error: 80h [Jul 05 08:39:52]: Set Cmd: ipmi_kcs_cmd: internal IPMI error [Jul 05 08:40:21]: Get Cmd: ipmi_kcs_cmd: driver timeout Strange enough, the watchdog reacts a lot quicker and more stable when I poll it through the network interface by ipmitool ... bmc watchdog reset or get. It immediately responds, always with correct values, and never shuts down. Maybe that's because I don't have any special driver loaded on Linux? The sun driver is not available for Linux as far as I understood, so I'm just using bmc-watchdog -g without any drivers. cu, Frank -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] configure: warning while processing for powerpc / Open embedded target
Hey Dick, Autoconf would define sys/io.h if it found it. So it must have found sys/io.h and asm/io.h? Al On Wed, 2010-07-07 at 07:40 -0700, dick.detwei...@emerson.com wrote: I'm going to be lazy here... Our cross-compile environment has io.h in asm/io.h. However, something must be defining HAVE_SYS_IO_H because that's what ipmi-kcs-driver.c ends up trying to include. Where are HAVE_[SYS/ASM]_IO_H determined and is there something I can do for a quick and dirty fix? Thanks again, Dick -Original Message- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Tuesday, July 06, 2010 5:53 PM To: Detweiler, Dick [NETPWR/AVOCENT/AL] Cc: freeipmi-devel@gnu.org Subject: Re: [Freeipmi-devel] configure: warning while processing for powerpc / Open embedded target Hey Dick, Personally, I've never seen this before. I don't use bitbake so I don't know much about it. But from the output, I'd guess that your bitmake build environment is missing some headers. I think what it's saying is if you have: /usr/include/example.h #include foo.h mycode.c: #include example.h autoconf is only checking for example.h, but because foo.h doesn't exist, it can't compile. Just a guess, hope it helps. Al On Tue, 2010-07-06 at 11:22 -0700, dick.detwei...@emerson.com wrote: Hi all, Running configure via bitbake and autoconf tool sets. They generated the following warning: configure: WARNING: sys/io.h: present but cannot be compiled configure: WARNING: sys/io.h: check for missing prerequisite headers? configure: WARNING: sys/io.h: see the Autoconf documentation configure: WARNING: sys/io.h: section Present But Cannot Be Compiled configure: WARNING: sys/io.h: proceeding with the preprocessor's result configure: WARNING: sys/io.h: in the future, the compiler will take precedence configure: WARNING: ## - ## configure: WARNING: ## Report this to freeipmi-devel@gnu.org ## configure: WARNING: ## - ## So I’ve now reported. What is the implication to this warning? 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.com www.**emersonnetworkpower.com -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Modifications necessary for our PPC environment.
Hey Dick,
2) Executing ipmiping on our target consistently resulted in Command line
option error.
This was tracked down to _cmdline_parse() in ping-tool-common.c. The
test:
while ((c = getopt (argc, argv, options)) != -1)
succeeds even when -1 is returned. This is a variable/constant size
issue as
the test is performed over 16 or 32 bits instead of the 8 bits desired.
I have
fixed the problem with:
while ((c = getopt (argc, argv, options)) != (char)-1)
Good catch. It'll be fixed in the next release, although I'll do it like below
instead:
--- common/src/pingtool/ping-tool-common.c 8 Feb 2010 22:02:30 -
1.22
+++ common/src/pingtool/ping-tool-common.c 8 Jul 2010 16:44:56 -
@@ -213,7 +213,8 @@ _cmdline_parse (int argc,
unsigned int max_sequence_number,
const char *options)
{
- char c, *ptr;
+ char *ptr;
+ int c;
/* Turn off error messages */
opterr = 0;
1) HAVE_SYS_IO_H and HAVE_ASM_IO_H are both defined in
config/config.h.
This happens because our build environment has both
/usr/include/asm/io.h and
/usr/include/sys/io.h present. However our cross compiler directory
chain only
has .../asm/io.h present. I believe the fix for this is for either
autoconf
or the configure script itself to test for cross compilation and then
look in the
correct directory tree for the include files.
I think the issue may be you're not setting your CFLAGS or paths
correctly. I don't know everything about cross-compiling but many
people use things like gcc's --sysroot to set things up properly.
Al
On Thu, 2010-07-08 at 08:10 -0700, dick.detwei...@emerson.com wrote:
Hi all,
I have gotten ipmiping to work on our PPC target platform but had to make two
edits to the freeipmi source that you may want to consider fixes for in the
future.
1) HAVE_SYS_IO_H and HAVE_ASM_IO_H are both defined in config/config.h.
This happens because our build environment has both
/usr/include/asm/io.h and
/usr/include/sys/io.h present. However our cross compiler directory
chain only
has .../asm/io.h present. I believe the fix for this is for either
autoconf
or the configure script itself to test for cross compilation and then
look in the
correct directory tree for the include files.
2) Executing ipmiping on our target consistently resulted in Command line
option error.
This was tracked down to _cmdline_parse() in ping-tool-common.c. The
test:
while ((c = getopt (argc, argv, options)) != -1)
succeeds even when -1 is returned. This is a variable/constant size
issue as
the test is performed over 16 or 32 bits instead of the 8 bits desired.
I have
fixed the problem with:
while ((c = getopt (argc, argv, options)) != (char)-1)
This is an easy fix, and I'll make sure it's in the next FreeIPMI release (and
in other areas getopt() is called).
Hopefully fixes for these can be included in the next release?
Thanks for your help in getting freeipmi up and working on our target.
Dick D.
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: Another FreeIPMI beta w/ BMC watchdog workaround for Sun machines
Hey Dave, On Wed, 2010-07-07 at 12:49 -0700, Dave Love wrote: Albert Chu ch...@llnl.gov writes: On the flip side, I've personally never tested on Solaris. So who knows if the /dev/bmc was really programmed correctly. I may have screwed up. Well the watchdog daemon has been running OK since June 29 on my Solaris system with the test freeipmi. I could potentially run extra tests that aren't at all risky on that box. Is this only happening on one motherboard? I have this feeling that maybe the board is just busted. I could try on some other x4 over Linux if necessary, but I'm busy, and don't actually need the watchdog working on them. Any additional testing is always welcome. But I wouldn't put too much effort into it. What Frank is seeing is so weird, it's hard to get a read if it's really the BMC firmware or something else. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Patch for SHA256 Support
Hi Holger, Thanks for the patch. This was on my todo, but w/o a motherboard to test on, I just let it linger. I think you forgot to add the appropriate permutation of cipher suite/SHA256 into libfreeipmi/src/debug/ and the manpages in common/man/, but no worries, I can add that myself. Only one question, are cipher suites 15-17 defined in the upcoming DCMI 1.1? ASAIK it hasn't been released publicly. I have a tiny concern about committing something that is not yet finalized. Or is DCMI 1.1 finalized and going to be released publicly soon?? Al On Thu, 2010-07-29 at 06:07 -0700, Liebig, Holger wrote: Hi all, please find attached the required modification for SHA256 and Cipher Suite 17 support in freeipmi. SHA256 has been added in IPMI 2.0 Errata 4 and is also one of the recommended Cipher Suites of the upcoming DCMI 1.1 Specification (where the Cipher Suite number is taken from). The modifications itself are straight forward, I just had to find all the places. Comments or feedback is more than welcome, especially if it works with other vendor implementations. Thanks, Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] FreeIPMI moving to subversion
The repo has been updated to SVN by the fine folks at Savannah. The new project head branch is: http://svn.savannah.gnu.org/svn/freeipmi/trunk is the new 0.8.X stable branch is: http://svn.savannah.gnu.org/svn/freeipmi/branches/Release-0_8_0_branch (these are for non-project members, project members, please adjust to use ssh). Al On Mon, 2010-08-09 at 16:06 -0700, Albert Chu wrote: Hey everyone, Just as a heads up, I plan to move the FreeIPMI repo from CVS to SVN sometime in the near future. So for those who may be cloning/updating/etc. from the repo, be aware that it'll change semi-soon. I'll send out info on appropriate paths/branches/etc. once the update has occurred. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hi Dan, In the fact, it would be better to use the function as part of interpret-oem-data within ipmi-sel, but it require better knowledge of current implementation of ipmi-sel than I have. Someone with better skills may implement it (using the code from patch). Then I can help with testing, if necessary. I had intended to add this into ipmi-sel, but w/o a mobo to test on I let it pass. If you're game to test a patch for me, I'd be glad to implement it into ipmi-sel. I'm busy right now, so it may take some time for me to get a patch together. Short term, I think we can add this patch into ipmi-oem as an extra OEM option for Fujitsu motherboards. BTW, what mobo are you running this on, so I can document in the future. Al On Sun, 2010-08-15 at 20:35 -0700, Dan Lukes wrote: Hi. The Fujitsu's iRMC has implemented proprietary function that return text representation of SEL. It's important especially for OEM-Reserved events. For example, the ipmi-sel show something like this: ipmi-sel --interpret-oem-data --display=1008 ID | Date| Time | Name | Type | Event 1008 | Dec-16-2009 | 15:40:29 | iRMC | OEM Reserved | Event Offset = 00h ; OEM Event Data2 code = 83h ; OEM Event Data3 code = 4Dh or ipmi-sel --interpret-oem-data --display=1032 ID | Date| Time | Name | Type | Event 1032 | Dec-16-2009 | 15:41:42 | iRMC | System Firmware Progress | System Firmware Error ; Unspecified ; OEM Event Data3 code = 5Fh utilising the OEM function we can get something like this: ipmi-oem -- fujitsu get-sel-entry-long-text 1008 1008 | Dec-16-2009 | 15:40:29 | INFORMATIONAL: Online firmware flash EEPROM 2 Version 3.77 or ipmi-oem -- fujitsu get-sel-entry-long-text 1032 1032 | Dec-16-2009 | 15:41:42 | Server Management Configuration NVRam bad, default configuration is used The implementation si based on (not so good) documentation: http://*manuals.ts.fujitsu.com/file/4390/irmc-s2-ug-en.pdf The patch that add the support for OEM/fujitsu/get-sel-entry-long-text into ipmi-oem is attached. It's tested on iRMC with firmware 3.77 In the fact, it would be better to use the function as part of interpret-oem-data within ipmi-sel, but it require better knowledge of current implementation of ipmi-sel than I have. Someone with better skills may implement it (using the code from patch). Then I can help with testing, if necessary. Hope it help, but you can freely ignore this message if not interested. Dan -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] Patch for SHA256 Support
Hey Holger, Thanks for the heads up, I can update ipmi-dcmi too :P Al P.S. I haven't forgotten about your SHA256 patch either. It's on my TODO. On Sun, 2010-08-15 at 23:50 -0700, Liebig, Holger wrote: Ok. I'll just hold off for the time being until it's published. That way it's sort of official. Only Cipher Suite 17 in the mentioned combination (3/4/1) is mentioned in the latest review copy of DCMI 1.1, that's why I skipped the other combinations. There seem to be (strong) requests from DCMI customers to add a stronger authentication algorithm than HMAC_SHA1, who knows why. Too bad Intel forgot to add the Cipher Suite Numbers into the IPMI 2.0 errata 4. There is no official announcement on the main DCMI page, but the updated DCMI Spec. 1.1 has been published to the Intel web site http://*www.*intel.com/go/DCMI http://*www.*intel.com/technology/product/dcmi/specification.htm Holger ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://*lists.gnu.org/mailman/listinfo/freeipmi-devel -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: ipmi-sensors abends when configuration file not specified at all
Hi Dan, On Mon, 2010-08-16 at 11:51 -0700, Dan Lukes wrote: On 08/16/10 19:55, Albert Chu: This should already be handled. Where you think it is handled ? In config_file_parse() there is eventually this line: if (!filename) filename = FREEIPMI_CONFIG_FILE_DEFAULT; and then filename is passed to the library conffile_parse() function. Al I found cmd_args-config_file = NULL; within _init_common_cmd_args (cmd_args) only. I found no other place called from ipmi-sensor that initialize config_file (not counting the command-line parser which doesn't apply when no --config-file option on command line) What version of FreeIPMI are you running? 0.8.8 Perhaps your freeipmi.conf has some typo in it that triggers a different bug? I have no freeipmi.conf at all. I'm fully satisfied with the defaults. If you will give me a hint where teh common.config_file is initialized to something else than NULL I will step the code in debugger and with some luck I will identify the place where the config_fiel is set back to NULL. Or, maybe, I will discover that code doesn't execute the line with initialization. But I can't found the line responsible for default initialization of config_file within ipmi-sensors's sources. Dan I hit the bug in the ipmi-sensors/src/ipmi-sensors-argp.c In the case the configuration file is not specified at all, the cmd_args-common.config_file == NULL Such situation is not handled correctly, the NULL is dereferenced and program abends. I suggest not to call config_file_parse() at all, when configration doesn't exist, e.g.: if (config_file_parse (cmd_args-common.config_file, should be changed to if (cmd_args-common.config_file != NULL config_file_parse (cmd_args-common.config_file, I tried it on my system and it helped. As alternative, such case can be handled inside of config_file_parse() function. -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
for Fujitsu motherboards. BTW, what mobo are you running this on, so I can document in the future. This feature/OEM command is available on all current BMC's from Fujitsu, even on the previous generation. The intention is to provide a consistent SEL translation and severity assignment across different tools. This also works for time stamped OEM SEL entries which we use for a limited auditing (e.g. login or power control from IP a.b.c.d). Unfortunately due to memory constrains in the previous BMC generation the maximum length of a single response is limited to 64bytes, while on the current product line you should be able to get the full 100bytes translated SEL text with a single request at least over LAN. Maximum (non standard) KCS transfer size is also different between current (255) and previous (64) generation, so the code should compare the data received with the total length reported in the response. If you want to double check for support of this OEM command beforehand, you can evaluate the Get Device Id response: Vendor ID: 0x2880 ProductId: should be = 0x0200 Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hey Dan, Finally got a chance to look through your patch. For the most part it's fine. I'll tweak a few formatting things to be consistent to other parts of FreeIPMI, and I think I'll do first and last instead of 0 or -1 for the first/last SEL entry. But I'm a tad confused on this in your printf at the end: data_len == text_len ? : ... (text incomplete)); Is there some subtlety of the get-sel-long-text OEM command that isn't clear to me (b/c I don't own one and haven't seen it in action)?? Al On Sun, 2010-08-15 at 20:35 -0700, Dan Lukes wrote: Hi. The Fujitsu's iRMC has implemented proprietary function that return text representation of SEL. It's important especially for OEM-Reserved events. For example, the ipmi-sel show something like this: ipmi-sel --interpret-oem-data --display=1008 ID | Date| Time | Name | Type | Event 1008 | Dec-16-2009 | 15:40:29 | iRMC | OEM Reserved | Event Offset = 00h ; OEM Event Data2 code = 83h ; OEM Event Data3 code = 4Dh or ipmi-sel --interpret-oem-data --display=1032 ID | Date| Time | Name | Type | Event 1032 | Dec-16-2009 | 15:41:42 | iRMC | System Firmware Progress | System Firmware Error ; Unspecified ; OEM Event Data3 code = 5Fh utilising the OEM function we can get something like this: ipmi-oem -- fujitsu get-sel-entry-long-text 1008 1008 | Dec-16-2009 | 15:40:29 | INFORMATIONAL: Online firmware flash EEPROM 2 Version 3.77 or ipmi-oem -- fujitsu get-sel-entry-long-text 1032 1032 | Dec-16-2009 | 15:41:42 | Server Management Configuration NVRam bad, default configuration is used The implementation si based on (not so good) documentation: http://*manuals.ts.fujitsu.com/file/4390/irmc-s2-ug-en.pdf The patch that add the support for OEM/fujitsu/get-sel-entry-long-text into ipmi-oem is attached. It's tested on iRMC with firmware 3.77 In the fact, it would be better to use the function as part of interpret-oem-data within ipmi-sel, but it require better knowledge of current implementation of ipmi-sel than I have. Someone with better skills may implement it (using the code from patch). Then I can help with testing, if necessary. Hope it help, but you can freely ignore this message if not interested. Dan -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hey Dan, On Tue, 2010-08-17 at 11:04 -0700, Albert Chu wrote: Hey Dan, Finally got a chance to look through your patch. For the most part it's fine. I'll tweak a few formatting things to be consistent to other parts of FreeIPMI, and I think I'll do first and last instead of 0 or -1 for the first/last SEL entry. But I'm a tad confused on this in your printf at the end: data_len == text_len ? : ... (text incomplete)); Ok, I think I get it now. In combination w/ Holger's response and understanding things more, there is no promise that all the text can come back in one response. I'll try and tweak your patch to iterate over multiple calls. Al Is there some subtlety of the get-sel-long-text OEM command that isn't clear to me (b/c I don't own one and haven't seen it in action)?? Al On Sun, 2010-08-15 at 20:35 -0700, Dan Lukes wrote: Hi. The Fujitsu's iRMC has implemented proprietary function that return text representation of SEL. It's important especially for OEM-Reserved events. For example, the ipmi-sel show something like this: ipmi-sel --interpret-oem-data --display=1008 ID | Date| Time | Name | Type | Event 1008 | Dec-16-2009 | 15:40:29 | iRMC | OEM Reserved | Event Offset = 00h ; OEM Event Data2 code = 83h ; OEM Event Data3 code = 4Dh or ipmi-sel --interpret-oem-data --display=1032 ID | Date| Time | Name | Type | Event 1032 | Dec-16-2009 | 15:41:42 | iRMC | System Firmware Progress | System Firmware Error ; Unspecified ; OEM Event Data3 code = 5Fh utilising the OEM function we can get something like this: ipmi-oem -- fujitsu get-sel-entry-long-text 1008 1008 | Dec-16-2009 | 15:40:29 | INFORMATIONAL: Online firmware flash EEPROM 2 Version 3.77 or ipmi-oem -- fujitsu get-sel-entry-long-text 1032 1032 | Dec-16-2009 | 15:41:42 | Server Management Configuration NVRam bad, default configuration is used The implementation si based on (not so good) documentation: http://**manuals.ts.fujitsu.com/file/4390/irmc-s2-ug-en.pdf The patch that add the support for OEM/fujitsu/get-sel-entry-long-text into ipmi-oem is attached. It's tested on iRMC with firmware 3.77 In the fact, it would be better to use the function as part of interpret-oem-data within ipmi-sel, but it require better knowledge of current implementation of ipmi-sel than I have. Someone with better skills may implement it (using the code from patch). Then I can help with testing, if necessary. Hope it help, but you can freely ignore this message if not interested. Dan -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: ipmi-sensors abends when configuration file not specified at all
Hey Dan,
Glad it's not a freeipmi issue. That is quite odd though.
Al
On Tue, 2010-08-17 at 13:04 -0700, Dan Lukes wrote:
On 08/16/10 22:40, Albert Chu:
This should already be handled.
You are true, problem is elsewhere.
I croped the sources to just:
---
int main (int argc, char **argv) {
char x[684*1024];
}
---
Compiled and linked:
gcc -shared -o .libs/ipmi-sensors ipmi-sensors.c
.libs/ipmi-sensors
And still:
Segmentation fault: 11 (core dumped)
Problem disappear when I remove '-shared' (but then it can't be linked
against libargp) or when I change [684*1024] to [683*1024] or less.
Conclusion: not FreeIPMI's problem, it's problem of GCC 4.2.1
So you can forged it ...
Dan
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hey Dan, Attached is my reworked patch for ipmi-oem. Can you give it a shot and LMK if it works? I cleaned up some chunks for code consistency to other code in ipmi-oem and added a manpage entry. I ended up removing the first and last because I guess I don't see users wanting to/commonly using it. Do you feel different? I can see last more often then first though (similar to how I have a 'tail' option in ipmi-sel, but not a 'head'). I did (atleast try) to implement the code to loop if there was more text to retrieve. Hopefully I implemented it right. Also, I slightly tweaked the output to more similarly match ipmi-sel output, adding in semi-colons and stuff. I admit, I'm not entirely sure of the output. You may have specifically chosen your output b/c it matches some other Fujitsu tool?? We can tweak as necessary. PLMK what you think. Al P.S. You'll probably get ChangeLog and NEWS conflicts in this patch, but you can ignore those of course. The code patches appear to apply cleanly to FreeIPMI 0.8.8. On Tue, 2010-08-17 at 12:13 -0700, Dan Lukes wrote: On 08/17/10 20:04, Albert Chu: I'll tweak a few formatting things to be consistent to other parts of FreeIPMI, and I think I'll do first and last instead of 0 or -1 for the first/last SEL entry. You are welcome. But I'm a tad confused on this in your printf at the end: data_len == text_len ? : ... (text incomplete)); Is there some subtlety of the get-sel-long-text OEM command that isn't clear to me Total size of message related to a SEL may be larger than specified MaxResponseDataSize (MaxResponseDataSize can't exceed 100 on my system or the call will fail). The data length field in response contain length of complete message (not the part returned just now). If you received incomplete message (e.g. actual length is less than claimed data length) then you can call function again, with non-zero Offset field in request, to obtain the rest of message. I didn't implemented repeated call so the text incomplete instead of it. Dan -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory Index: AUTHORS === --- AUTHORS (revision 7219) +++ AUTHORS (working copy) @@ -18,6 +18,7 @@ Jan Forch jan.fo...@sun.com Fillod Stephane stephane.fil...@grassvalley.com Holger Liebig holger.lie...@ts.fujitsu.com +Dan Lukes d...@obluda.cz and others ... Package Maintainers: Index: NEWS === --- NEWS (revision 7219) +++ NEWS (working copy) @@ -3,6 +3,7 @@ o In ipmi-sel and ipmimonitoring, workaround Supermicro H8QME SEL compliance issues in ipmi-sel. o In ipmi-sel, do not report error if SEL is empty. +o Support Fujitsu 'get-sel-entry-long-text' in ipmi-oem. o Revert 'Open Session Privilege Workaround' changes in 0.8.8, were unnecessary. o Fix daylight savings bug when configuring BMC times in bmc-device. o Support 'veryslowcommit' workaround for config tools to work around Index: ChangeLog === --- ChangeLog (revision 7219) +++ ChangeLog (working copy) @@ -1,3 +1,20 @@ +2010-08-17 Albert Chu ch...@llnl.gov + + * ipmi-oem/: Re-format Fujitsu get-sel-entry-long-text for + consistency to remaining ipmi-oem code. Re-work to go through + multiple iterations. + + * Add manpage entry for Fujitsu get-sel-entry-long-text OEM + command. + +2010-08-17 Dan Lukes d...@obluda.cz + + * ipmi-oem/: Support Fujitsu get-sel-entry-long-text OEM command. + +2010-08-13 Albert Chu ch...@llnl.gov + + * ipmi-oem/: Various code consistency cleanup. + 2010-08-06 Albert Chu ch...@llnl.gov * Fix SOL_Retry_Count validation bug. Index: ipmi-oem/src/ipmi-oem-fujitsu.c === --- ipmi-oem/src/ipmi-oem-fujitsu.c (revision 7219) +++ ipmi-oem/src/ipmi-oem-fujitsu.c (working copy) @@ -223,6 +223,23 @@ #define IPMI_OEM_FUJITSU_ERROR_LED_CSS_BLINK_GEL_ON7 #define IPMI_OEM_FUJITSU_ERROR_LED_CSS_BLINK_GEL_BLINK 8 +/* achu: one byte field, so max is 255 */ +#define IPMI_OEM_FUJITSU_SEL_ENTRY_LONG_TEXT_MAX_STRING_LENGTH 255 + +#define IPMI_OEM_FUJITSU_CSS_BITMASK 0x80 +#define IPMI_OEM_FUJITSU_CSS_SHIFT7 + +#define IPMI_OEM_FUJITSU_SEVERITY_BITMASK 0x70 +#define IPMI_OEM_FUJITSU_SEVERITY_SHIFT 4 + +#define IPMI_OEM_FUJITSU_CSS_COMPONENT1 +#define IPMI_OEM_FUJITSU_NO_CSS_COMPONENT 0 + +#define IPMI_OEM_FUJITSU_SEVERITY_INFORMATIONAL 0 +#define IPMI_OEM_FUJITSU_SEVERITY_MINOR 1 +#define IPMI_OEM_FUJITSU_SEVERITY_MAJOR 2 +#define IPMI_OEM_FUJITSU_SEVERITY_CRITICAL 3 + static int _ipmi_oem_get_power_source (ipmi_oem_state_data_t *state_data, uint8_t command_specifier, @@ -1290,3 +1307,214 @@ cleanup
Re: [Freeipmi-devel] Patch for SHA256 Support
Hey Holger, Finally got your patch merged in. Added the manpage entries and the debug support. Do you think you could try out the final patch below to make sure I didn't break anything? Could you also try --debug in a tool to see if the debug output comes out looking right too? Thanks, Al On Thu, 2010-07-29 at 06:07 -0700, Liebig, Holger wrote: Hi all, please find attached the required modification for SHA256 and Cipher Suite 17 support in freeipmi. SHA256 has been added in IPMI 2.0 Errata 4 and is also one of the recommended Cipher Suites of the upcoming DCMI 1.1 Specification (where the Cipher Suite number is taken from). The modifications itself are straight forward, I just had to find all the places. Comments or feedback is more than welcome, especially if it works with other vendor implementations. Thanks, Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory Index: libfreeipmi/include/freeipmi/interface/ipmi-rmcpplus-interface.h === --- libfreeipmi/include/freeipmi/interface/ipmi-rmcpplus-interface.h (revision 7200) +++ libfreeipmi/include/freeipmi/interface/ipmi-rmcpplus-interface.h (working copy) @@ -84,7 +84,7 @@ #define IPMI_AUTHENTICATION_ALGORITHM_RAKP_NONE 0x00 #define IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA1 0x01 #define IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_MD5 0x02 -#define IPMI_AUTHENTICATION_ALGOIRTHM_RAKP_HMAC_SHA2560x03 +#define IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA2560x03 /* C0h - FFh - OEM */ /* all other reserved */ @@ -92,12 +92,13 @@ (((__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_NONE \ || (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA1 \ || (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_MD5 \ -|| (__algorithm) == IPMI_AUTHENTICATION_ALGOIRTHM_RAKP_HMAC_SHA256) ? 1 : 0) +|| (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA256) ? 1 : 0) #define IPMI_AUTHENTICATION_ALGORITHM_SUPPORTED(__algorithm) \ (((__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_NONE \ || (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA1 \ -|| (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_MD5) ? 1 : 0) +|| (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_MD5 \ +|| (__algorithm) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_HMAC_SHA256) ? 1 : 0) / * IPMI 2.0 Integrity Algorithm Numbers * @@ -110,6 +111,7 @@ #define IPMI_INTEGRITY_ALGORITHM_HMAC_SHA256_128 0x04 /* C0h - FFh - OEM */ /* all other reserved */ + #define IPMI_INTEGRITY_ALGORITHM_VALID(__algorithm) \ (((__algorithm) == IPMI_INTEGRITY_ALGORITHM_NONE\ || (__algorithm) == IPMI_INTEGRITY_ALGORITHM_HMAC_SHA1_96 \ @@ -121,7 +123,8 @@ (((__algorithm) == IPMI_INTEGRITY_ALGORITHM_NONE\ || (__algorithm) == IPMI_INTEGRITY_ALGORITHM_HMAC_SHA1_96 \ || (__algorithm) == IPMI_INTEGRITY_ALGORITHM_HMAC_MD5_128 \ -|| (__algorithm) == IPMI_INTEGRITY_ALGORITHM_MD5_128) ? 1 : 0) +|| (__algorithm) == IPMI_INTEGRITY_ALGORITHM_MD5_128 \ +|| (__algorithm) == IPMI_INTEGRITY_ALGORITHM_HMAC_SHA256_128) ? 1 : 0) /** * IPMI 2.0 Confidentiality Algorithm Numbers * @@ -178,14 +181,18 @@ #define IPMI_HMAC_MD5_DIGEST_LENGTH 16 #define IPMI_MD5_DIGEST_LENGTH16 #define IPMI_HMAC_SHA1_96_DIGEST_LENGTH 12 +#define IPMI_HMAC_SHA256_DIGEST_LENGTH32 #define IPMI_HMAC_SHA1_96_AUTHENTICATION_CODE_LENGTH 12 #define IPMI_HMAC_MD5_128_AUTHENTICATION_CODE_LENGTH 16 #define IPMI_MD5_128_AUTHENTICATION_CODE_LENGTH 16 +#define IPMI_HMAC_SHA256_128_AUTHENTICATION_CODE_LENGTH 16 /* Refer to table 22-19 */ +/* XXX - Errata 4 defines SHA256 but not cipher suite IDs */ +/* Cipher Suite 17 confirmed via DCMI 1.1 specification */ #define IPMI_CIPHER_SUITE_ID_MIN 0 -#define IPMI_CIPHER_SUITE_ID_MAX 14 +#define IPMI_CIPHER_SUITE_ID_MAX 17 /* * fill* functions return 0 on success, -1 on error. Index: libfreeipmi/include/freeipmi/util/ipmi-cipher-suite-util.h === --- libfreeipmi/include/freeipmi/util/ipmi-cipher-suite-util.h (revision 7200) +++ libfreeipmi/include/freeipmi/util/ipmi-cipher-suite-util.h (working copy) @@ -27,63 +27,90 @@ #include freeipmi/interface/ipmi-rmcpplus-interface.h #define IPMI_CIPHER_SUITE_COMBINATION_VALID(__a, __i, __c) \ + /* Cipher Suite 0 */ \ __a) == IPMI_AUTHENTICATION_ALGORITHM_RAKP_NONE \ (__i
[Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hey Dan,
Responses inlined below.
On Tue, 2010-08-17 at 16:19 -0700, Dan Lukes wrote:
On 08/17/10 23:10, Albert Chu:
Attached is my reworked patch for ipmi-oem. Can you give it a shot and
LMK if it works?
Done. Some notes:
1. --
if user call for record id = 65536 the number record ID is silently
changed to something else. I recommend not to allow out-of-range values
at all.
Doh! Good catch.
2. --
bytes_rq[8] = UCHAR_MAX;
Requests with MaxResponseDataSize100 will fail.
Also response packet can't be larger than IPMI_OEM_MAX_BYTES
So you can't ask for more than min(IPMI_OEM_MAX_BYTES-17,100) bytes.
Ahhh. That's a subtlety I didn't get. Also, based on Holger's earlier
response (which now makes more sense to me).
---
Unfortunately due to memory constrains in the previous BMC generation
the maximum length of a single response is limited to 64bytes, while on
the current product line you should be able to get the full 100bytes
translated SEL text with a single request at least over LAN. Maximum
(non standard) KCS transfer size is also different between current (255)
and previous (64) generation, so the code should compare the data
received with the total length reported in the response.
We should probably use 64 instead of 100.
3. --
component_length = (rs_len - 16);
I prefer more safe approach - I assume that string may end before packet
end (e.g. len is obtained by strlen). And I doesn't assume that string
is '\0' terminated in response also.
The so-called documentation from Fujitsu is so vague to be trusted so
much, IMHO ...
4.
... in advance, you count the length including the trailing '\0' (which
is present in every response - not only the last part of string), so the
concatenation doesn't work (off-by-one bug)
Ahh, this wasn't clear in the Fujitsu docs. I'll add a comment to make
that more clear.
5.
while (offset data_length)
... will be neverending loop when
IPMI_OEM_FUJITSU_SEL_ENTRY_LONG_TEXT_MAX_STRING_LENGTH data_length
You should replace
offset = IPMI_OEM_FUJITSU_SEL_ENTRY_LONG_TEXT_MAX_STRING_LENGTH
with
offset = data_length
to resolve the issue. Or use break; ...
6.
bytes_rq array need not to be intialized every round (only offset is
changing). Also, most of results needs to be extracted from bytes_rs
only once.
7.
If user asked for 'first' or 'last' record then use actual_record id for
subsequent (looped) requests to obtain consistent results as last SEL
may become non-last in meantime.
==
I did (atleast try) to implement the code to loop if there was more text
to retrieve. Hopefully I implemented it right.
See [4], [5] and [7]
Also, I slightly tweaked the output to more similarly match ipmi-sel
output, adding in semi-colons and stuff. I admit, I'm not entirely sure
of the output. You may have specifically chosen your output
I tried to follow output format of ipmi-sel.
I attached the another iteration of patch.
Dan
Attached is the current diff I have in ipmi-oem compared to freeipmi
0.8.8. Look good?
Al
--
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory
Index: ipmi-oem/src/ipmi-oem-fujitsu.c
===
--- ipmi-oem/src/ipmi-oem-fujitsu.c (revision 7219)
+++ ipmi-oem/src/ipmi-oem-fujitsu.c (working copy)
@@ -223,6 +223,25 @@
#define IPMI_OEM_FUJITSU_ERROR_LED_CSS_BLINK_GEL_ON7
#define IPMI_OEM_FUJITSU_ERROR_LED_CSS_BLINK_GEL_BLINK 8
+/* achu: one byte field, so max is 255 */
+#define IPMI_OEM_FUJITSU_SEL_ENTRY_LONG_TEXT_MAX_STRING_LENGTH 255
+
+#define IPMI_OEM_FUJITSU_CSS_BITMASK 0x80
+#define IPMI_OEM_FUJITSU_CSS_SHIFT7
+
+#define IPMI_OEM_FUJITSU_SEVERITY_BITMASK 0x70
+#define IPMI_OEM_FUJITSU_SEVERITY_SHIFT 4
+
+#define IPMI_OEM_FUJITSU_CSS_COMPONENT1
+#define IPMI_OEM_FUJITSU_NO_CSS_COMPONENT 0
+
+#define IPMI_OEM_FUJITSU_SEVERITY_INFORMATIONAL 0
+#define IPMI_OEM_FUJITSU_SEVERITY_MINOR 1
+#define IPMI_OEM_FUJITSU_SEVERITY_MAJOR 2
+#define IPMI_OEM_FUJITSU_SEVERITY_CRITICAL 3
+
+#define ipmi_oem_min(a,b) ((a) (b) ? (a) : (b))
+
static int
_ipmi_oem_get_power_source (ipmi_oem_state_data_t *state_data,
uint8_t command_specifier,
@@ -1290,3 +1309,247 @@
cleanup:
return (rv);
}
+
+int
+ipmi_oem_fujitsu_get_sel_entry_long_text (ipmi_oem_state_data_t *state_data)
+{
+ uint8_t bytes_rq[IPMI_OEM_MAX_BYTES];
+ uint8_t bytes_rs[IPMI_OEM_MAX_BYTES];
+ int rs_len;
+ long value;
+ uint16_t sel_record_id;
+ uint16_t actual_record_id = 0;
+ uint32_t timestamp = 0;
+ uint8_t css = 0;
+ uint8_t severity = 0;
+ time_t timetmp;
+ struct tm time_tm;
+ char time_buf[IPMI_OEM_TIME_BUFLEN + 1];
+ char
RE: [Freeipmi-devel] Re: Fujitsu's SDR cache bug
] 172.17.15.238: [ 0h] = comp_code[ 8b] 172.17.15.238: [h] = next_record_id[16b] 172.17.15.238: [ BYTE ARRAY ... ] = record_data[16B] 172.17.15.238: [ 70h 17h 51h 12h 1Bh 20h 00h 00h ] 172.17.15.238: [ 00h 00h 00h 00h 00h 00h 00h C7h ] 172.17.15.238: IPMI Trailer: 172.17.15.238: -- 172.17.15.238: [ F3h] = checksum2[ 8b] 172.17.15.238: = 172.17.15.238: IPMI 1.5 Get SDR Request 172.17.15.238: = 172.17.15.238: RMCP Header: 172.17.15.238: 172.17.15.238: [ 6h] = version[ 8b] 172.17.15.238: [ 0h] = reserved[ 8b] 172.17.15.238: [ FFh] = sequence_number[ 8b] 172.17.15.238: [ 7h] = message_class.class[ 5b] 172.17.15.238: [ 0h] = message_class.reserved[ 2b] 172.17.15.238: [ 0h] = message_class.ack[ 1b] 172.17.15.238: IPMI Session Header: 172.17.15.238: 172.17.15.238: [ 2h] = authentication_type[ 8b] 172.17.15.238: [ 19Ch] = session_sequence_number[32b] 172.17.15.238: [40771024h] = session_id[32b] 172.17.15.238: [ BYTE ARRAY ... ] = authentication_code[16B] 172.17.15.238: [ 63h 38h 04h 82h B8h FDh B1h 2Ah ] 172.17.15.238: [ 50h 8Dh 61h 31h F0h 2Fh 39h E7h ] 172.17.15.238: [ Dh] = ipmi_msg_len[ 8b] 172.17.15.238: IPMI Message Header: 172.17.15.238: 172.17.15.238: [ 20h] = rs_addr[ 8b] 172.17.15.238: [ 0h] = rs_lun[ 2b] 172.17.15.238: [ Ah] = net_fn[ 6b] 172.17.15.238: [ B8h] = checksum1[ 8b] 172.17.15.238: [ 81h] = rq_addr[ 8b] 172.17.15.238: [ 0h] = rq_lun[ 2b] 172.17.15.238: [ 39h] = rq_seq[ 6b] 172.17.15.238: IPMI Command Data: 172.17.15.238: -- 172.17.15.238: [ 23h] = cmd[ 8b] 172.17.15.238: [ 6h] = reservation_id[16b] 172.17.15.238: [1770h] = record_id[16b] 172.17.15.238: [ 10h] = offset_into_record[ 8b] 172.17.15.238: [ 10h] = bytes_to_read[ 8b] 172.17.15.238: IPMI Trailer: 172.17.15.238: -- 172.17.15.238: [ CBh] = checksum2[ 8b] 172.17.15.238: = 172.17.15.238: IPMI 1.5 Get SDR Response 172.17.15.238: = 172.17.15.238: RMCP Header: 172.17.15.238: 172.17.15.238: [ 6h] = version[ 8b] 172.17.15.238: [ 0h] = reserved[ 8b] 172.17.15.238: [ FFh] = sequence_number[ 8b] 172.17.15.238: [ 7h] = message_class.class[ 5b] 172.17.15.238: [ 0h] = message_class.reserved[ 2b] 172.17.15.238: [ 0h] = message_class.ack[ 1b] 172.17.15.238: IPMI Session Header: 172.17.15.238: 172.17.15.238: [ 2h] = authentication_type[ 8b] 172.17.15.238: [ 6C21E58h] = session_sequence_number[32b] 172.17.15.238: [40771024h] = session_id[32b] 172.17.15.238: [ BYTE ARRAY ... ] = authentication_code[16B] 172.17.15.238: [ 84h 70h 63h 54h 73h 78h 49h 39h ] 172.17.15.238: [ EDh 47h 06h 75h 6Dh 6Eh FFh 3Fh ] 172.17.15.238: [ 1Ah] = ipmi_msg_len[ 8b] 172.17.15.238: IPMI Message Header: 172.17.15.238: 172.17.15.238: [ 81h] = rq_addr[ 8b] 172.17.15.238: [ 0h] = rq_lun[ 2b] 172.17.15.238: [ Bh] = net_fn[ 6b] 172.17.15.238: [ 53h] = checksum1[ 8b] 172.17.15.238: [ 20h] = rs_addr[ 8b] 172.17.15.238: [ 0h] = rs_lun[ 2b] 172.17.15.238: [ 39h] = rq_seq[ 6b] 172.17.15.238: IPMI Command Data: 172.17.15.238: -- 172.17.15.238: [ 23h] = cmd[ 8b] 172.17.15.238: [ 0h] = comp_code[ 8b] 172.17.15.238: [h] = next_record_id[16b] 172.17.15.238: [ BYTE ARRAY ... ] = record_data[16B] 172.17.15.238: [ 69h 52h 4Dh 43h 20h 53h 32h 00h ] 172.17.15.238: [ 00h 00h 00h 00h 00h 00h 00h 00h ] 172.17.15.238: IPMI Trailer: 172.17.15.238: -- 172.17.15.238: [ EBh] = checksum2[ 8b] -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
Hey Holger, On Wed, 2010-08-18 at 08:25 -0700, Liebig, Holger wrote: Hey Holger, If you can, that'd be great (LMK if you begin something, so I won't start to work on it too). Because this wouldn't be a straight OEM code - string conversion (you're instead calling another Fujitsu IPMI call), there will be subtleties that I know I'm going to mess up on that you may just know off the top of your head. The key OEM extension support would be added into libfreeipmi/src/sel-parse/. If you take a look in there, you'll already see a whole bunch of files for SEL OEM extension support for Dell, Inventec, Quanta, etc. I imagine a Fujitsu equivalent could just be plugged right in. Based on the Dan's e-mail: [Liebig, Holger] I have at least found the place to plug/glue this somewhat into the OEM record decoding functionality, so there is at least some starting point. Since this OEM command can - or should ;) - decode all possible SEL entries, I will try to find the other places and see how it goes from there. One problem is, that this OEM command requires admin privilege, which would have to be specified on the command line with -l admin. That is annoying. We could up the default privilege to admin, but my general attitude is to max the privilege level at whatever is necessary for the tool. Since this is an OEM extension thing, it's a little different. Perhaps we could document it and if you run w/ --interpret-oem-data, output an error if user isn't specifying atleast admin privilege??? Not entirely sure at this point, we'll ponder this a bit more. Al Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
RE: [Freeipmi-devel] Re: Fujitsu's iRMC S2 - support for get SEL entry long text within ipmi-oem
On Fri, 2010-08-20 at 05:20 -0700, Liebig, Holger wrote: One problem is, that this OEM command requires admin privilege, which would have to be specified on the command line with -l admin. That is annoying. We could up the default privilege to admin, but my general attitude is to max the privilege level at whatever is necessary for the tool. Since this is an OEM extension thing, it's a little different. Perhaps we could document it and if you run w/ --interpret-oem-data, output an error if user isn't specifying atleast admin privilege??? Not entirely sure at this point, we'll ponder this a bit more. [Liebig, Holger] At least some hint to the user would be nice. Since completion code 0xD4 is returned (insufficient Privilege), this could be potentially in lined into the output Well, if we did nothing, a privilege level insufficient ... error could would fallthrough from libfreeipmi/ to ipmi-sel's execution. Not good, but not terrible. As I've thought about it more, I'm thinking the --interpret-oem-data option should have a special case for Fujitsu motherboards and report an error to the user just saying, Use -l admin. I'm also working on integration of Fujitsu specific OEM sensor information into freeipmi, at least this would show some better information for the SEL than today when running without -l admin but with --interpret-oem-data. Cool! Al Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] FreeIPMI 0.8.9 Released
http://ftp.gluster.com/pub/freeipmi/0.8.8/ FreeIPMI 0.8.9 - 08/20/10 - o In ipmi-sel and ipmimonitoring, workaround Supermicro H8QME SEL compliance issues in ipmi-sel. o In ipmi-sel, do not report error if SEL is empty. o Support Fujitsu 'get-sel-entry-long-text' in ipmi-oem. o Fix workaround flags bug in ipmimonitoring. o Revert 'Open Session Privilege Workaround' changes in 0.8.8, were unnecessary. o Fix daylight savings bug when configuring BMC times in bmc-device. o Support 'veryslowcommit' workaround for config tools to work around very slow BMCs. o Support --enable-rawdumps compile option. o Support SHA256 in IPMI 2.0. o Other minor bug fixes. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
[Freeipmi-devel] Re: [Freeipmi-users] FreeIPMI 0.8.9 Released
Oops, didn't update the link properly. http://ftp.gluster.com/pub/freeipmi/0.8.9/ Al On Fri, 2010-08-20 at 13:51 -0700, Albert Chu wrote: http://ftp.gluster.com/pub/freeipmi/0.8.8/ FreeIPMI 0.8.9 - 08/20/10 - o In ipmi-sel and ipmimonitoring, workaround Supermicro H8QME SEL compliance issues in ipmi-sel. o In ipmi-sel, do not report error if SEL is empty. o Support Fujitsu 'get-sel-entry-long-text' in ipmi-oem. o Fix workaround flags bug in ipmimonitoring. o Revert 'Open Session Privilege Workaround' changes in 0.8.8, were unnecessary. o Fix daylight savings bug when configuring BMC times in bmc-device. o Support 'veryslowcommit' workaround for config tools to work around very slow BMCs. o Support --enable-rawdumps compile option. o Support SHA256 in IPMI 2.0. o Other minor bug fixes. Al -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Re: Patch for Fujitsu OEM Sensor Types and SEL decoding
to the output. Dependend from the command line arguments you will get the following outputs: No additional arguments: 20 | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers (2880h) | OEM defined = 10h 02h C0h A8h 33h 6Ah --interpret-oem-data 20 | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers (2880h) | (admin privilege required for full OEM decoding) OEM defined = 10h 02h C0h A8h 33h 6Ah --interpret-oem-data -l admin 20 | Aug-27-2010 | 05:00:16 | Manufacturer ID = Fujitsu Siemens Computers (2880h) | INFORMATIONAL: iRMC Browser user 'admin' AVR Session started from 192.168.51.106 And for ipmi-sensors: No additional arguments 2000 | DIMM-1A | OEM Reserved| N/A| N/A | 'Unrecognized State' --interpret-oem-data 2000 | DIMM-1A | OEM Memory Status | N/A| N/A | 'OK' Holger -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
