I've been looking at FreeIPMI for the past few days for use on clusters
of Dell 1950/2950/1435 nodes. For the most part, it's perfectly suited
for the task, but I've run into a couple of problems and found some
features I'd like to see, and perhaps implement in-house.
I'd like to work with the co
On Thu, 2007-04-19 at 22:18 -0700, Albert Chu wrote:
> Hi Levi,
>
> I think it's done. PLMK if it works for you on the dell's.
>
> our CVS head (our 0.4.0 eventual release)
>
> cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/freeipmi co
> freeipmi
>
> our 0.3.X maintenance line
>
> cvs -z3 -d:p
On Thu, 2007-04-19 at 15:51 -0700, Al Chu wrote:
> > I'd like the ability to enter the key in hexadecimal
> > and have it treated as a 20-byte binary field instead of a string, which
> > matches how the key is handled in the Dell utilities.
>
> I faced a similar issue/dilemma early on. Honestly,
On Mon, 2007-04-23 at 11:54 -0700, Al Chu wrote:
> Cool. Perhaps we could add the K_g fixes you need (are working on??),
> then we could roll out 0.3.3.
>
I'll be working on a patch for the K_g key today; I'll post it sometime
in the next few days for your review.
--Levi
In an attempt to build the FreeIPMI CVS trunk on a SuSE 9.3 (x86-64)
with 2.9.6 kernel headers, we got some errors while it tried to build
the openipmi support libraries. Perhaps the openipmi support could be
made a configure-level option? Errors were as follows:
>From configure:
checking linux
I decided to try this first for the ipmipower command, since it didn't
have the off-by-one bug in the k_g key handling to complicate things.
I'll get to that next, if everyone's happy with how I did this.
I decided to go with the hex by default, strings prefixed with s:
method. I left out the -'s
On Wed, 2007-04-25 at 15:51 -0700, Al Chu wrote:
> Hey Levi,
>
> It seems I hit the same errors as you did (after installing
> linux/ipmi.h, which isn't installed by default on RHEL4). The '__user'
> #define seems to have issues.
>
> Anyways, I did a patch that seems to resolve the problem. C
On Wed, 2007-04-25 at 18:28 -0700, Al Chu wrote:
>
> Thinking about this a bit. I think the hex mode should be the non-
> default. The reason is that atleast a few other apps (most notably
> Conman) already assume string input by default. Some others might have
> scripts and such. Would it be
This version should address the issues from the review of the previous
patch. I've tested this one a bit more and it seems pretty solid to me.
If you like it, I'll carry on making these changes in the other
2.0-aware utilities, starting with ipmiconsole.
--Levi
Index: common/src/
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
Index: common/src/ipmi-common.c
===
On Fri, 2007-04-27 at 17:28 -0700, Albert Chu wrote:
> 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?
Yup, I'll be working on
Here's the ipmiconsole patch, this time against the cvs trunk. Had a
bit of trouble yesterday checking out the latest version, since it turns
out savannah went through a server OS upgrade and it messed up the cvs
config. I found someone who could help on IRC, so it's working again
now.
I'll now
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
On Fri, 2007-05-04 at 14:41 -0700, Al Chu wrote:
> just added two docs, comments are welcome:
>
> doc/freeipmi-coding.txt - coding style intro, explanation of coding
> decisions done in libfreeipmi.
I like it so far, though it doesn't seem to address some of the issues
that you found in my initia
I was reviewing the k_g hex input/output as it exists in the CVS trunk
now, and I ran across a problem. Fortunately, it should only show
itself when debugging is enabled. Here's the issue: When printing the
k_g key in hex, the caller of format_kg must allocate sufficient memory
to hold it. I be
I'm playing around with libipmiconsole to figure out how to use it to
access multiple consoles at once. Looking at the exported API and the
implementation, I'm curious how non-blocking context submissions are
supposed to be handled.
The ipmiconsole_engine_submit_block implementation adds a flag
On Tue, 2007-05-29 at 20:57 -0700, Albert Chu wrote:
> I've now added a ipmiconsole_ctx_status() API function that I believe
> addresses this issue (this is only in the CVS head).
>
> Al
This sounds like a great solution to me. Thanks!
--Levi
Is there currently any plan to provide OEM-specific decoding of SEL
event data fields? On the Dell boards we're using, for example, the
DIMM slot number is recorded in some of the bits of the Event Data
field. It would be useful to us to be able to specify the OEM of the
board and have it apply w
On Mon, 2007-06-25 at 16:35 -0700, Al Chu wrote:
> There currently isn't a road-map, just b/c we haven't had a need. We'd
> gladly welcome support.
>
> I guess somewhere within ipmi-sel we'd have to run the get device id
> command (I think that's the one) which can get the manufacturer id.
> Th
The comment in ipmiconsole.h for ipmiconsole_engine_teardown() says that
the function will block until all active contexts are closed, but
instead it seems to return immediately. After perusing the code, it
does seem to trigger the closing of active connections and the death of
the engine threads,
On Thu, 2007-06-28 at 08:42 -0700, Al Chu wrote:
> Hey Levi,
>
> Thanks for noticing this. I'm guessing that the implementation changed
> awhile back and I forgot to change the comments.
>
> I need to look at the code again the refresh my memory on how best to
> implement this. Looking at ipmic
On Thu, 2007-06-28 at 08:42 -0700, Al Chu wrote:
> Hey Levi,
>
> Thanks for noticing this. I'm guessing that the implementation changed
> awhile back and I forgot to change the comments.
>
> I need to look at the code again the refresh my memory on how best to
> implement this. Looking at ipmic
On Thu, 2007-06-28 at 09:19 -0700, Al Chu wrote:
> I really view the engine and the contexts as two separate "objects" the
> user is responsible for. The user "creates" each context and thus is
> responsible for "destroying" each one. The user "inits" the engine and
> responsible for "destroying
On Thu, 2007-06-28 at 09:39 -0700, Al Chu wrote:
>
> So is it not closing the sessions?
>
Apparently not.
> > It would be handy to have a call that
> > does trigger the closing of all sessions such that ipmi_ctx_destroy()
> > will work on them afterward, though.
>
> The library should work suc
On Thu, 2007-06-28 at 15:33 -0700, Al Chu wrote:
> Hey Levi,
>
> One other additional note. I added several debug flags into the
> library. It may be worth adding it into your code to help us figure out
> the problem. Passing
>
> IPMICONSOLE_DEBUG_FILE
>
> to engine_init() will output debug
On Thu, 2007-06-28 at 16:47 -0600, Levi Pearson wrote:
> On Thu, 2007-06-28 at 15:33 -0700, Al Chu wrote:
> > Hey Levi,
> >
> > One other additional note. I added several debug flags into the
> > library. It may be worth adding it into your code to help us figure ou
Here's a message and patch from Troy Telford, one of the LNXI system
software engineers in charge of maintaining our HiPer package
repository:
Attatched is the patch I made to the freeipmi .specfile.
The problem is pretty simple: on Red Hat distros, the macro
%{_initrddir}
evaluates to /etc/rc.
27 matches
Mail list logo
