Matt Domsch wrote:
Lots of good changes to the driver lately that userspace will care
about the version of the driver. Bump the version from 36.0 to 38.0
to be higher than 37 that the 2.4 driver came out with a few weeks ago
which doesn't have all the same changes.
Signed-off-by: Matt Domsch
Pierre Sangouard wrote:
Hi,
I've encountered 2 small bugs in lanserv (OpenIPMI 1.4.21). Here is a patch
fixing them.
Regards,
Pierre
This patch should completely fix the get session info in lanserv.
Thanks,
-Corey
Index: include/OpenIPMI/lanserv.h
Eugen Leitl wrote:
I understand the SunFire X2100 service processor
IPMI 1.5 is a standard Tyan SMDC (and so is the
whole motherboard, in fact).
I presume I'm covered with Debian AMD64? I should be, but haven't
seen anything conclusive in the archives.
I haven't heard anything, but if it
Thanks, I've been meaning to get this in, but things have been crazy as
I have been travelling. Hopefully early next week.
You can send to LKML yourself if you like. I'll respond, the fix is
definately correct.
-Corey
Matt Domsch wrote:
The IPMI specifcation says the generator ID is
coly wrote:
hi, I read IPMI A Gentle Introduction with OpenIPMI these days. I
find this doc is written in August 19, 2004, so I wanna if there is
any new version for this file.
The most current version is in CVS. I thought I had uploaded a new
version to the web site, but I guess I didn't.
Yani Ioannou wrote:
Hi Corey,
Just wondering if you've had time to review this patch yet, or any
comments on how it should be improved? I'd really like to see it move
forward so I could continue my work with bmcsensors.
Thanks,
Yani
Dang, I have been way to busy with other stuff. I'll try
This is integrated into CVS now and will be in the next 2.0 release
(coming up this weekend, hopefully).
-Corey
coly wrote:
hi, I add editline into openipmi as a library, and link it into
openipmish.
now, openipmish can support history commands, by up and down arrow key.
Corey:
1, the
You are building a 64-bit application and it is trying to link against
32-bit libraries.
This is an unfortunate problem with 64-bit systems, libtool, and
autoconf. libtool finds /usr/lib/libnetsnmp.la and uses that to
configure itself. I'm not exactly sure how to disable it, but I know a
couple
It's something I need to fix; I haven't done an RPM build since I added
that utility. I should have a new release out today, I've just found a
nasty bug I've been chasing for a while.
-Corey
coly wrote:
hi, today I tried to build a rpm package by typing make rpm. but it
failed. the message
I answered this on the HPI mailing list, but FYI, here's the answer...
An ATCA board is supposed to implement a graceful shutdown operation
with the payload when it goes to M6 state. How this is implemented is
not defined, and if the OS in question does not properly handle things,
there can be
It depends on what you need. You can run OpenIPMI on the payload board;
newer versions should automatically detect that it is running on a
payload ATCA board and not go out on the bus and scan for things. (on
older versions you can ask it to not scan the bus). So you can get to
the board's
This is the wrong mailing list, you need to ask the ipmitool people.
However, from the messages, I'd say that the user you are logging in as
doesn't have necessary privileges to connect. You probably need to set
the user to have admin privileges.
-Corey
Eugen Leitl wrote:
I'm having basic
You probably need something like the attached patch. Cross building sucks.
-Corey
ZhiHuaXu wrote:
hi，
When I use the cross-complie tools compile the openipmi,there are some
errors.
My linux's vesion is 2.4.20 and the openipmi's vesion is 1.4.26.
[EMAIL PROTECTED]
-off-by: Matt Domsch [EMAIL PROTECTED]
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index b36eef0..96a9e24 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1184,20 +1184,20
I just sits on the PCI bus instead of the ISA bus or I2C bus. Nothing
different besides that. Newer versions of the driver should find it
automagically.
-Corey
Arunkumar S wrote:
Hi,
What is a PCI based BMC. I came to know that HP's iLO2 controller
belongs to that kind. How does it
interface
the BMC uses to talk to the main processor.
-Corey
Arun.
Corey Minyard wrote:
I just sits on the PCI bus instead of the ISA bus or I2C bus. Nothing
different besides that. Newer versions of the driver should find it
automagically.
-Corey
Arunkumar S wrote:
Hi,
What
I've finished the GUI rewrite finally, the OpenIPMI GUI should be much
more accessible to people now. No functional differences, really, it
just uses Tkinter and Tix instead of wxPython.
If people would try this out, it would be great. Please report any bugs
you find. Note that I have seen
Sorry, I've been on vacation for a week and am just getting caught up.
I'm adding the following to the FAQ:
2.22) What crypto does OpenIPMI implement/use?
OpenIPMI implements MD2 and MD5. It's questionable whether those
are crypto algorithms or not, but I'm including them just to be
with other tasks. Call schedule() instead.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.17/drivers/char/ipmi/ipmi_si_intf.c
===
--- linux-2.6.17.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.17/drivers/char
I'm not really supporting the 2.4 drivers any more, but IMHO this
is really a BIOS problem. The BIOS should be able to recover the I2C
interface even if it is in the middle of a transaction.
Do you think this is a problem with the 2.6 driver? It doesn't have a
thread that does this, but does it
This patch looks good to me. I added the following as a header.
Is this ok? The Signed-off-by line is pretty important in patches.
Thanks,
-Corey
--
This patch adds the ability to register for a command per-channel in
the IPMI driver.
If your BMC supports multiple channels, incoming messages
I forgot to test the SMB driver before release (I *thought* I had tested
it), but there were problems with it. I have updated the driver on
Sourceforge with one I have tested.
-Corey
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with
The driver does all this work. Basically, it has to for allowing
mutliple users. Responses that come in to the msg buffer will come in
as responses. Commands that come in to the msg buffer will come to the
application that has registered to receive the message via the
IPMICTL_REGISTER_FOR_CMD
Well, the sample code is really not meant to be run, it's an example of
how to use the library. But you should see some output. It should
print out something like:
[EMAIL PROTECTED]:~/sf/OpenIPMI/OpenIPMI$ sample/ipmisample lan
t-chesnee-1 623 md5 admin
INFO: 0
Arun Babu wrote:
I am trying to write an application which needs to perform certain
operation on a sensor exceeding thresholds.
The sample3.c provided with the distribution is very useful and I
tried it..
1. The program detects sensors and are reported successfully. (It
reports reading
Thanks, looks good.
-Corey
Matt Domsch wrote:
Patch from Jordan Hargrave and Chris Poblete, as various versions of
udev have had either /sbin/udev and/or /sbin/udevd, so test for
either.
Patch committed to CVS HEAD and rel_1_4.
Thanks,
Matt
Philipp Matthias Hahn wrote:
Matt Domsch wrote:
On Mon, Aug 14, 2006 at 06:14:46PM +0200, Philipp Matthias Hahn wrote:
While playing with openipmigui, the server just rebooted with the
following last message:
BUG: soft lockup detected on CPU#0!
c0103416 show_trace+0xd/0xf
I forgot to mention that the v37 code does actually make sense.
Everything Matt has worked on has gone to the mainstream kernel, so all
Matt's changes should be there, either already in v37, or in future
patches to the main kernel.
-Corey
Corey Minyard wrote:
I'm going to be out for a little
to dig through the mail archives to find it.
Thank you very much again for your consideration and help with this
issue.
Carol Hebert
LTC System x Enablement
IBM Corp.
Date: Mon, 24 Jul 2006 19:18:54 -0500
From: Corey Minyard [EMAIL PROTECTED]
Subject: Re: [Openipmi-developer] Need help
headers
in the patches that came from 2.6 so you can review them.
Thanks,
-Corey
Corey Minyard wrote:
I've spent some time today working on this. My strategy is to go from
the v37 driver (which is both in the 2.6 kernel and 2.4 kernel) and go
forward from there from lkml patches
, but this structure
is large enough that I would perfer to not do that.
Thanks Olaf!
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Cc: Olaf Kirch [EMAIL PROTECTED]
Index: linux-2.6.17/drivers/char/ipmi/ipmi_msghandler.c
===
--- linux
Roger Mach wrote:
I took a look at these patchsets and they appear to be good, with just a
couple of minor issues.
Thanks for taking time to look at this.
First, I encountered a compiler error when
building ipmi_kcs_intf.c that I believe was already reported on the
ipmitool-devel list
Gurpreet Singh wrote:
I was looking at the sensor information of Intel 1U machine and here
is the extracted information for Hard drives. I was wondering about
the status field and was not able to decode these values. Here is the
output of the sensor information for hard drives:
Drv 1
[EMAIL PROTECTED] wrote:
Hi,
I noticed some patches by David about serial interface support. I have a
need to talk to BMC that is
connected over a serial port. What is status of the serial patch? How can I
get all the files needed to
use serial interface support in OpenIPMI in 2.6.13 kernel.
[EMAIL PROTECTED] wrote:
I am not the David mentioned in the previous email, but I also have a
serial interface driver that I've been working on which uses a line
discipline instead of hooking into the serial driver directly. The
only drawback is that you can't send messages at panic time.
[EMAIL PROTECTED] wrote:
In cases where console is on a separate serial port, does panic string
still has to go to BMC ? I have a scenario where the
interface between host processor and BMC is serial and there is another
serial port on host that is the console
The console is independent of
It looks like you are using RHEL4. In that case, I'd suggest you run
(not walk :-) to Matt Domsch's page at
http://linux.dell.com/files/openipmi and pick up the updates there.
-Corey
Raghavendra G wrote:
Hi all,
I am trying to load IPMI drivers on Hp Integrity cx2600. The Kernel
version I
Due to demand, the 2.4 driver has been updated to be basically the same
level as the 2.6 driver.
You have three kernel options: 2.4.20 (which had no IPMI driver
originally), 2.4.21 (which has a very primitive version of the driver)
and 2.4.32. This patch brings all those version to as close to
Matt Domsch wrote:
On Thu, Sep 28, 2006 at 09:24:42AM -0700, Bela Lubkin wrote:
Corey Minyard wrote:
* The user sends a cold reset to the BMC. The BMC will be resetting
and thus will not be able to respond for some period of time. The
driver, when it sees the cold
to having the timer shut
off cleanly when the watchdog daemon is killed intentionally on an
otherwise healthy system?
Thanks much for your help,
Carol Hebert
On Mon, 2006-08-14 at 19:17 -0500, Corey Minyard wrote:
Doug Ambrisko wrote:
Dmitry Frolov writes:
| * Carol Hebert [EMAIL
Carson Gaspar wrote:
--On Thursday, September 28, 2006 8:45 PM -0500 Corey Minyard
[EMAIL PROTECTED] wrote:
I guess the big question in my mind is why you would ever want to stop
the watchdog daemon for long enough to allow the watchdog to go off. It
seems you are opening a window
have broken
interrupts, a blacklist will need to be added.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.18/drivers/char/ipmi/ipmi_si_intf.c
===
--- linux-2.6.18.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.18
Carol Hebert wrote:
Regarding the question of why anyone would want to stop the daemon, I
guess there could be reasons why someone would want to stop it
(temporarily). Maybe they would want to change the
timeout/pretimeout/action/etc. settings during ipmi_watchdog module
insertion time
interrupts or users that are not concerned with
performance can turn it on or off to their liking.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.18/Documentation/IPMI.txt
===
--- linux-2.6.18.orig/Documentation/IPMI.txt
The basic problem is that platform_device_alloc() is being called with
the device id, but not the product id as part of the name. According to
the spec, The combo of the two is required to be unique on a machine.
But the device id is the same on both BMCs, it appears.
Carol, can you confirm
Hopefully the attached patch will fix the problem and clean up the error
handling in this failure case.
-Corey
Carol Hebert wrote:
Hi Corey,
I believe I may have found a problem with the ipmi driver v39 in the
2.6.18 kernel when loaded on multi-node systems (in my particular case,
an
Goh, Yen Mei wrote:
Hi,
Not sure why, I encountered intermittent failure while issuing get
deviceid as below. I don’t see this issue in MontaVista 3.1, but only
saw it on RHEL4. Just wonder if there is any different on this driver
for these 2 different Linux? Or timing/time out issue?
:28:44 localhost kernel: IPMI message handler: BMC returned
incorrect response, expected netfn 7 cmd 1, got netfn 2b cmd 1c
Thanks,
YM
-Original Message-
From: Corey Minyard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 10:28 PM
To: Goh, Yen Mei
Cc: Corey Minyard
wait on this one, then, but I decided it would be pretty easy to do
through the hotplug subsystem.
-Corey
Thanks very much,
Carol Hebert
On Wed, 2006-10-11 at 10:25 -0500, Corey Minyard wrote:
Now the driver is doing exactly what it is supposed to do, but now that
may not be what we want
Goh, Yen Mei wrote:
Thanks. Yes, the V13.12 driver got install.
Any idea on why this problem could happen and how to resolve it? Heard
from Corey that there is a similar problem seen before as well. Is it
possible to have MV3.1 driver installed in RHEL4? Thanks a lot for help.
Issue:
Got
Thanks,
YM
-Original Message-
From: Corey Minyard [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 9:04 PM
To: Goh, Yen Mei
Cc: openipmi-developer@lists.sourceforge.net
Subject: Re: [Openipmi-developer] Get intermitent failure for IPMI raw
command
Goh, Yen Mei wrote
You don't give enough information for me to understand exactly what you
are doing, but there are some problems with what you have done. The
driver handles doing the get message automatically, you don't have to do
anything. All you need to do is send your original command and wait for
the
Corey Minyard wrote:
Please let me know what I can do to help. In the meantime, I'll take a
look at the current code and try to figure out why it's still oopsing.
I thought the oops was fixed. If not, can you send one?
As far as things you can do, I'm not really sure. I don't have
/sys/devices/platform/ipmi_si.0/uevent
# ls -l /dev/ipmi*
crw--- 1 root root 252, 0 Oct 18 11:52 /dev/ipmi0
crw--- 1 root root 252, 1 Oct 18 11:52 /dev/ipmi1
On Tue, 2006-10-17 at 17:22 -0500, Corey Minyard wrote:
Corey Minyard wrote:
Please let me know what I can do
coly wrote:
Corey:
I found some compiling error when build OpenIPMI packages, this is a
patch based on 2.0.8. Please review it, thank you!
Coly
--- cmdlang/ipmish.c
+++ cmdlang/ipmish.c
@@ -382,6 +382,7 @@
@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
This patch removes the arbitrary limit of number of IPMI interfaces.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.18/drivers/char/ipmi/ipmi_msghandler.c
Carol Hebert wrote:
Hi,
Wow! I barely hit return on my email and the patch was in my
inbox!! :-)
Well, I had it sitting there, so it was easy. Sorry about the compile
errors, those fixes had snuck into a later patch but didn't get put into
the right place.
I'm waiting for one more patch
Carol Hebert wrote:
On Thu, 2006-10-19 at 21:46 -0500, Corey Minyard wrote:
.
I'm waiting for one more patch to be finished up and tested, and I'm
putting out a 2.6.18 patch set.
That's excellent news! I'll run the patch set on my multi-nodes as soon
as it's out. BTW: I
Dang unsigned values. Thanks for the report and the backtrace.
Here's a patch that should fix the problem. It only will occur if an
entity association record is the first entry in the SDRs.
-Corey
Index: lib/entity.c
===
RCS file:
Raghavendra G wrote:
Hi,
Is there a way to obtain the mapping between the Logical and Physical
slot numbers? The Ipmi 1.5 specification says that it is stored in the
Shelf EPROM. But the Spec doesnt say at what offset it is stored in
the ROM. Are there any IPMI commands which can retrieve
Lelievre, Frederic wrote:
Hi Corey,
The previous version of the driver was retrying on the SendMessage failures,
no matter the return code received. Now it filters some of the error code
such as the lost of arbitration and perform retries on those. The problem is
that when the failure is
The current set of changes are rather major in the FRU and ATCA areas,
so this is current a release-candidate for people to test. Get it at
http://sourceforge.net/project/showfiles.php?group_id=36127package_id=181090
This release has two major functional improvements:
* You can now edit and
Zvika Shaubi wrote:
Here is a log of the two commands:
mc info
MC
Name: zzz(0.82)
Active: false
The MC is inactive, meaning it is reported as being possibly present,
but is not current present in the system. That's why there is no
information on it.
I'm not sure why this
Yet another pre-release. There were some problems with the FRU handling
calculating offsets when adding/removing. Also, the interface for this
was not as clean as I would have liked for modifying the FRU
information, and I have redone it so some extent. I also fixed some of
the other problems I
Carol Hebert wrote:
Hi Corey,
I wanted to let you know about some of the testing I've done with some
of the new 39.1 patches and also to ask you about an issue I found.
First, I wanted to ask you about the ipmi-remove-device-interface-limits
patch. It seems that when I have this patch
the changelog:
2006-11-16 Corey Minyard [EMAIL PROTECTED]
* lib/entity.c: ipmi_entity_fetch_frus_cb() violated the rule of
returning an error and still calling the done handler (and it
didn't check the done handler for NULL). Fix this problem.
* swig/python/openipmigui/_saveprefs.py
Bela Lubkin wrote:
Corey Minyard wrote:
Corey
Corey I was able to analyze the raw data and figure out what is going on,
and
Corey as I said, ipmitool is wrong. And I believe the BMC is issuing an
Corey incorrect response. The Sensor Owner ID in the SDR for that sensor
is
Corey 0xb1
X86 boards generally use ACPI for the power management interactions
with the BMC. However, non-x86 boards need some help. This patch
adds the help for the Motorola PigeonPoint-based IPMCs.
Signed-off-by: Joseph Barnett [EMAIL PROTECTED]
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index
[EMAIL PROTECTED]
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.19-rc6/drivers/char/ipmi/ipmi_bt_sm.c
===
--- linux-2.6.19-rc6.orig/drivers/char/ipmi/ipmi_bt_sm.c
+++ linux-2.6.19-rc6/drivers/char/ipmi/ipmi_bt_sm.c
Increase the maximum message size a KCS interface supports to the
maximum message size the rest of the driver supports. Some systems
really support messages this big.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Cc: Patrick Schoeller [EMAIL PROTECTED]
Index: linux-2.6.19-rc6/drivers/char
Randy Dunlap wrote:
Randy Dunlap wrote:
Bela Lubkin wrote:
Andrew Morton wrote:
Sometime, please go through the IPMI code looking for all these
statically-allocated things which are initialised to 0 or NULL and
remove
all those intialisations? They're unneeded, they increase the
vmlinux
Andrew Morton wrote:
On Fri, 1 Dec 2006 22:24:22 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
This patch removes the arbitrary limit of number of IPMI interfaces.
This has been tested with 8 interfaces.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Cc: Carol Hebert [EMAIL PROTECTED
Ok, patch is in my tree with some minor changes required due to other
changes that have gone in since 2.6.19.
Christian Krafft wrote:
+};
+
+static void __devinit of_find_bmc(void)
+{
+ of_register_platform_driver(ipmi_of_platform_driver);
+}
+#endif /* CONFIG_PM_OF */
I took the
this causes false negatives for fans that are not
spinning, because that bit is also used for telling if the sensor cannot
be read properly.
So I'm not sure if the situation can be correctly resolved in fielded
systems without writing custom code for each chassis type :-(.
-Corey
Corey Minyard wrote
-
From: Corey Minyard [mailto:[EMAIL PROTECTED]
Sent: Friday, January 05, 2007 9:44 AM
To: Chandrasekharapuram Venkateswaran-CVC008
Cc: [EMAIL PROTECTED];
openipmi-developer@lists.sourceforge.net
Subject: Re: [Openipmi-developer] openIPMI
In reviewing the information
It's not necessarily the case that OpenIPMI is wrong (though it is
possible). The algorithm for entity presence is complicated and subtle
and subject to interpretation in places. If you want a headache, you
can read about it in section 40 of the IPMI 2.0 spec.
I'd have to spend some time
.
Putting in a wart specific to this system board wouldn't work because
there are several configurations of the system board with/without IMM.
Andy
-Original Message-
From: Corey Minyard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 23, 2007 4:01 PM
To: Cress, Andrew R
Cc: [EMAIL
[EMAIL PROTECTED] wrote:
Corey,
Here is the patch (RHEL5 base code) I've been testing that detects the ACPI
namespace object.
The IPI0001 device doesn't contain the register spacing directly; it has a
_CRS resource object that
(for KCS) has two I/O port entries. I save the first port
Ivánszky Gábor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I'm trying to use ipmi kernel driver on a HP Proliant ML110 G3.
As I see the latest openipmi supported kernel is 2.6.18, so I use a
2.6.18.8 (from kernel.org). I patched it with 2.6.18-v39.1 ipmi driver.
I got
Gabor Ivanszky wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, so it is not really a development issue, sorry for bothering you
with that.
It may be a development issue. Hard to say at this point.
Usually the BIOS has something to talk to be BMC in the setup, is
that
I haven't seen this problem, but it appears to be order related and
that's probably why I missed it.
I think the right answer is to move the call to uart_register_ldrv() out
of uart_configure_port() and move it into uart_add_one_port() after the
mutex-state is unlocked. However, I haven't
That may be the case for OEM events (which have no standard defined MC)
or events from boards that are no longer in the system. If that's the
case, it's normal.
If the MC the event is from is still valid, then there's a problem. I
can't reproduce, it seems to work fine for me.
-Corey
Jesse
If you are using the SI driver, then there is nothing new that is not
already in Andrew's or Linus' kernel.
The SMB driver needs to be brought up to date, but that is just patch
monkeying.
The serial driver needs a lot of work. I could bring the current
version up to date, but that's not
You are not trying to run OpenIPMI, you are trying to run ipmitool,
which is a different project. Please ask on that mailing list.
-corey
Rodrigo Ferreira Valentim wrote:
Hi.
I need to access IPMI from LAN in both Windows/Linux OS.
So I try to run OpenIpmi 1.8.9 in Ubuntu 7.0.4 and in
David Jenkins wrote:
Corey,
Okay. I will go with OEM event.
Ok, thanks.
We received notification this week that Pigeon Point has implemented
hpm.1 (?) firmware upgrade method in their code.
They indicated that this is a true IPMI standard that others will be
using as well. I haven't
I checked this out and it seems to work fine. This does seem a little
nicer than the way it was, so if this is the way the kernel is heading
I'll ack it.
-corey
Jan Engelhardt wrote:
Change Kconfig objects from menu, config into menuconfig so
that the user can disable the whole feature
[EMAIL PROTECTED] wrote:
Hii all,
using OpenIPMI API, i am going to get
remote (over the LAN) IPMI server hardware parameter
(like sensor details), anybody have sample code for
this,pls send me.
Using OpenIPMI API how to send request and receive response over LAN.
[EMAIL PROTECTED] wrote:
Hii all,
My requirement as follows,
from the localhost i am going to give the IPMI commands using OpenIPMI \
ipmicmd -k \\\f 0 4 2d 1\\\ lan 210.210.65.108 623 \\\none\\\
\\\user\\\ \\\uername\\\ \\\password\\\ \ to the remote IPMI enabled
server
(over the
[EMAIL PROTECTED] wrote:
Hii all,
the iterate function what is doing,
suppose my domian have the 10 entities ,whether it will call 10 times to the
handle_entity function
for different entity.pls tell me what this
\ipmi_domain_iterate_entities(domain, handle_entity,
The concept of parents and children is not the same as the entities
containment in the domain. Listing the entities in the domain will list
all of them, all parents and children. The parent/child relationships
are used to denote physical containment (like a memory chip being on a
memory
[EMAIL PROTECTED] wrote:
Hii all,
ipmi_domain_iterate_entities(domain,handle_entity,my_data);
Whether the above API will list all entities in the
domain?
Thanks,
barani
I will list all the entities in the domain at the time it is called.
When the domain is
[EMAIL PROTECTED] wrote:
Hii all,
int ipmi_mc_get_users(ipmi_mc_t *mc,
unsigned int channel,
unsigned int user,
ipmi_user_list_cb handler,
void *cb_data);
in the above
[EMAIL PROTECTED] wrote:
Hii all,
int ipmi_mc_get_users(ipmi_mc_t *mc,
unsigned int channel,
unsigned int user,
ipmi_user_list_cb handler,
void *cb_data);
Using the above
All those things are specific to an MC, some of them are specific to a
channel on an MC. So you have to do this on the right MC.
-corey
[EMAIL PROTECTED] wrote:
Hii all,
in a domain i have set of MCs.
The users, connection ,channel, are specfic to a MC (or) global to
Commands like help sensor will be quite handy. There are commands to
list all the sensors and get their current values, settings, etc.
-corey
[EMAIL PROTECTED] wrote:
Hii all,
using \'ipmish\' i want get the sensor related information pls give some
example.
Thanks
barani
[EMAIL PROTECTED] wrote:
Hii all,
Accessing SDRs for a system, i am using below code, whether it will give
SDRs information in a
system
//mycode.c
ipmi_sdr_info_t *sdrs;
rv = ipmi_sdr_info_alloc(domain, NULL, 0, 0, sdrs);
ipmi_sdr_fetch(sdrs, sdrs_fetched, tmp_obj);
Well, this program has a race condition, because there is no guarantee
that ipmi_init() in first_thread runs before second_thread(). You
should alloc the os handler and call ipmi_init() in the main routine and
first_thread should just call the operation loop. I'm surprised the
program
[EMAIL PROTECTED] wrote:
Hii all,
ipmi_domain_close(domain, close_timeout, tmp_obj);
using the above function i am closing the lan connection, whether it stop,
the running operation_loop (os_hnd-operation_loop(os_hnd);)
You don't need to close and re-open the domain. First of all,
See the function read_sensor_states() in cmdlang/cmd_sensor.c. It gets
a reading and iterates through it. You really shouldn't be directly
using ipmi_get_reading_name(), you should use
ipmi_sensor_reading_name_string(). If there are OEM plugins that modify
these values, they may not exactly
the initial message, second
paragraph). Ipmitool finds states for these sensors so something is not
quite right. These sensors are in fact OEM; is there a different set of
state functions that I need to use for OEM?
Thanks again,
Jen
-Original Message-
From: Corey Minyard [mailto
1 - 100 of 979 matches
Mail list logo
