Re: [Openipmi-developer] [RFC PATCH 1/4] IPMI: Add one interface to get more info of low-level IPMI device

[Corey Minyard]

On 10/14/2010 08:07 PM, ykzhao wrote:
>
>> The way you are doing it, there is no need for a refcount, since you are
>> making a copy of the data.
>>
>> Is a copy or a pointer better?  A pointer is generally preferred, it
>> keeps from having to either store data on the stack or dynamically
>> allocate it for the copy.  But it's not a huge deal in this case.  A
>> pointer will require you to dynamically allocate the smi_info structure
>> so you can free it separately.  But then only the top-level put routine
>> is required, it can simply free the structure if the refcount is zero.
>>  
> When the pointer mechanism is used, we will have to allocate the
> smi_info structure dynamically. Every time the function of
> ipmi_get_smi_info, it will be allocated dynamically. And if it fails in
> the allocation, we can't return the expected value.
>
Well, you misunderstand.  You allocate one copy when the SMI info is 
created.  And you return a pointer to that with the refcount 
incremented.  No need to allocate a new one on each call.  Use the 
refcounts to know when to free it.

> But when the copy is used, it will be much simpler.  It is the caller's
> responsibility to prepare the corresponding data structure. They can
> define it on stack. Of course they can also dynamically allocate it.
>
> Can we choose the copy mechanism to make it much simpler?
>
Sure, I think I already said this :).  Just get rid of the refcount stuff.

-corey

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [RFC PATCH 1/4] IPMI: Add one interface to get more info of low-level IPMI device

[Corey Minyard]

Well, no, you are returning a pointer to something that is in the smi 
data structure.  For that you would need a refcount, because that 
structure can cease to exist asynchronously to your code.  Instead, just 
pass in the structure you want to fill in.  Like:

int ipmi_get_smi_info(int if_num, struct ipmi_smi_info *data)
{
/* checks here */

handlers = intf->handlers;
rv = handlers->get_smi_info(intf->send_info, data);
}

static int get_smi_info(void *send_info,
struct ipmi_smi_info *data)
{
struct smi_info *new_smi = send_info;

data->smi_info.dev = new_smi->dev;
data->addr_src = new_smi->addr_source;
data->smi_info.addr_info = new_smi->addr_info;

return 0;
}



Why are you passing an address type in to the function?  That means you 
would have to know the address type to get anything out of if.  It would 
be better to just return the info and let the user do the comparison.  
That way, if something wanted to fetch the info to get the device, or 
some other info, you don't have to try every address type.

Speaking of the device, that is a refcounted structure.  You can't just 
pass it back without doing refcounts on it.

Can you rename the union addr_info, and comment that which union 
structure is used depends on the address type?

Also, I don't know anything about this ACPI handle, but is that a 
permanent structure?  Can you just grab it like you do and pass it 
around?  I would guess not.

-corey

On 10/22/2010 04:10 AM, yakui.z...@intel.com wrote:
> From: Zhao Yakui
>
> The IPMI smi_watcher will be used to catch the IPMI interface as they come or 
> go.
> In order to communicate with the correct IPMI device, it should be confirmed
>   whether it is what we wanted especially on the system with multiple IPMI
> devices. But the new_smi callback function of smi_watcher provides very
> limited info(only the interface number and dev pointer) and there is no
> detailed info about the low level interface. For example: which mechansim
> registers the IPMI interface(ACPI, PCI, DMI and so on).
>
> This is to add one interface that can get more info of low-level IPMI
> device. For example: the ACPI device handle will be returned for the pnp_acpi
> IPMI device.
>
> Signed-off-by: Zhao Yakui
> ---
> In this patch only the info of pnp_acpi IPMI is provided. If the detailed info
> is also required for other mechanism, please add them in the structure of
> ipmi_smi_info.
>
>   drivers/char/ipmi/ipmi_msghandler.c |   26 ++
>   drivers/char/ipmi/ipmi_si_intf.c|   28 
>   include/linux/ipmi.h|   23 +++
>   include/linux/ipmi_smi.h|   11 +++
>   4 files changed, 84 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
> b/drivers/char/ipmi/ipmi_msghandler.c
> index 4f3f8c9..6f4da59 100644
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@ -970,6 +970,32 @@ out_kfree:
>   }
>   EXPORT_SYMBOL(ipmi_create_user);
>
> +int ipmi_get_smi_info(int if_num, enum ipmi_addr_src type,
> + struct ipmi_smi_info **data)
> +{
> + int   rv = 0;
> + ipmi_smi_tintf;
> + struct ipmi_smi_handlers *handlers;
> +
> + mutex_lock(&ipmi_interfaces_mutex);
> + list_for_each_entry_rcu(intf,&ipmi_interfaces, link) {
> + if (intf->intf_num == if_num)
> + goto found;
> + }
> + /* Not found, return an error */
> + rv = -EINVAL;
> + mutex_unlock(&ipmi_interfaces_mutex);
> + return rv;
> +
> +found:
> + handlers = intf->handlers;
> + rv = handlers->get_smi_info(intf->send_info, type, data);
> + mutex_unlock(&ipmi_interfaces_mutex);
> +
> + return rv;
> +}
> +EXPORT_SYMBOL(ipmi_get_smi_info);
> +
>   static void free_user(struct kref *ref)
>   {
>   ipmi_user_t user = container_of(ref, struct ipmi_user, refcount);
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 7bd7c45..73b1c82 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -57,6 +57,7 @@
>   #include
>   #include
>   #include
> +#include
>   #include
>   #include
>   #include "ipmi_si_sm.h"
> @@ -107,10 +108,6 @@ enum si_type {
>   };
>   static char *si_to_str[] = { "kcs", "smic", "bt" };
>
> -enum ipmi_addr_src {
> - SI_INVALID = 0, SI_HOTMOD, SI_HARDCODED, SI_SPMI, SI_ACPI, SI_SMBIOS,
> - SI_PCI, SI_DEVICETREE, SI_DEFAULT
> -};
>   static char *ipmi_addr_src_to_str[] = { NULL, "hotmod", "hardcoded", "SPMI",
>   "ACPI", "SMBIOS", "PCI",
>   "device-tree", "default" };
> @@ -291,6 +288,7 @@ struct smi_info {
>   struct task_struct *thread;
>
>   struct list_head link;
> + struct ipmi_smi_info smi_data;
>   };
>
>   #define smi_inc_

Re: [Openipmi-developer] [RFC PATCH 1/4] IPMI: Add one interface to get more info of low-level IPMI device

[Corey Minyard]

On 11/02/2010 12:33 AM, ykzhao wrote:
> On Thu, 2010-10-28 at 09:00 +0800, ykzhao wrote:
>
>> On Thu, 2010-10-28 at 00:13 +0800, Corey Minyard wrote:
>>  
>>> I think you miss the point of a refcount.  The refcount is to keep the
>>> data structure around even if the device has gone away, so that any
>>> users may not crash.  Just having a counter in the IPMI structure and
>>> then decrementing the device refcount is not going to accomplish anything.
>>>
>>> And you don't really need to refcount the IPMI structure.  (And if you
>>> did, you would need to use a refcount structure and you would need to
>>> keep from freeing the IPMI structure until the refcount went to zero.)
>>> You just need to increment the refcount on the device structure, and
>>> whoever gets the device structure needs to be responsible for
>>> decrementing it's refcount.
>>>
>> Yes. After the copy mechanism is used, it is unnecessary to use the
>> refcount to protect the corresponding data structure.
>>
>> In fact the purpose of adding another one refcount is to add/decrease
>> the refcount of dev in course of calling the function of
>> ipmi_get_smi_info/ipmi_put_smi_info.
>>   But after I look at the smi_watcher mechanism, I find that the
>> refcount of dev is not released correctly in the following case.
>>  Step 1:  Other driver registers one smi_watcher and the
>> ipmi_get_smi_info is called in the new_smi callback function. (And the
>> driver will use the dev pointer before the ipmi_put_smi_info is
>> called).
>>  Step 2: for any reason, the IPMI device will be unregistered by 
>> calling
>> cleanup_one_si. This function will remove it from the IPMI device list
>> firstly and then call the smi_gone for every smi_watcher.
>>  Step 3: the ipmi_put_smi_info is called in smi_gone callback 
>> function.
>> In such case the ipmi_put_smi_info can't find the corresponding IPMI
>> device based on the given if_num and can't release the pointer of dev.
>>
>> But after adding another refcount, we can handle the above scenario. At
>> the same time even when the ipmi_put_smi_info is not called by the
>> caller, it still can work.
>> Not sure whether the above thought is redundant?
>>  
> Corey,
>  Is the above thought correct? If not, please correct me. In fact the
> purpose of adding another refcount is to fix the incorrect inc/dec in
> course of calling ipmi_get_smi_info/ipmi_put_smi_info.
>

No.  The purpose of a refcount is to keep from freeing a data structure 
while it is in use.

Let's say your code gets the device structure for the IPMI device, then 
a task switch occurs.  During the time it is not running, the IPMI 
device is hotplugged away and no longer exists.  The device is deleted.  
When your code starts running again, it still has a pointer to that 
device structure.  Sure, the removal code may have run, but your code 
still has a pointer to that device structure.  Which has been freed.  Bad.

This is what refcounts (well, krefs) do.  In the above scenario, your 
code will get the device with the kref incremented.  All the above 
happens, but since you have incremented the refcount on the device 
structure, it will not be deleted.  It will wait until you put 
(decrement) the refcount before performing the free.

>
>>
>>  
>>> I'd also prefer to not have a struct ipmi_smi_info in the IPMI data
>>> structure.  Just pull the data from existing sources.
>>>
>> At most cases the requirement is different for the different addr source
>> type. If we don't put the ipmi_smi_info in the IPMI data structure, I am
>> afraid that we will have to fill the corresponding info based on the
>> addr source type. Maybe it will be more complex.
>>  
> If only pull data from the existing source, it can save some
> memory-space. But it seems a bit complex as we have to fill the info
> based on the corresponding addr source type. And this should be done
> every time the function of ipmi_get_smi_info is called.
>

I don't think it's that complex, and I doubt that function is called 
that often.

-corey
>
>> Thanks.
>>  Yakui
>>
>>  
>>> -corey
>>>
>>> On 10/26/2010 04:14 AM, yakui.z...@intel.com wrote:
>>>
>>>> From: Zhao Yakui
>>>>
>>>> The IPMI smi_watcher will be used to catch the IPMI interface as they come 
>>>> or go.
>>>> In order to communicate with the correct IPMI device, it should be 
>&g

Re: [Openipmi-developer] [PATCH 0/3_v14] IPMI/ACPI: Install the ACPI IPMI opregion

[Corey Minyard]

On 12/13/2010 11:21 PM, Len Brown wrote:
> Corey,
> Most of the code is in drivers/acpi, but that depends on the ipmi part.
> Shall I take all three patches in the acpi-test tree?
>
> thanks,
> Len Brown, Intel Open Source Technology Center
>
I was trying to figure out what to do with these, so yes, I think that 
pulling them into the acpi-test tree is good.  They won't get tested any 
other way, I don't think.

Thanks,

-corey

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] Add missing space in start_now parameter description

[Corey Minyard]

Looks good to me.

Acked-by: Corey Minyard 

On 12/17/2010 05:38 PM, dann frazier wrote:
> Signed-off-by: dann frazier
> ---
>   drivers/char/ipmi/ipmi_watchdog.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_watchdog.c 
> b/drivers/char/ipmi/ipmi_watchdog.c
> index f4d334f..9b12da5 100644
> --- a/drivers/char/ipmi/ipmi_watchdog.c
> +++ b/drivers/char/ipmi/ipmi_watchdog.c
> @@ -314,7 +314,7 @@ MODULE_PARM_DESC(preop, "Pretimeout driver operation.  
> One of: "
>"preop_none, preop_panic, preop_give_data.");
>
>   module_param(start_now, int, 0444);
> -MODULE_PARM_DESC(start_now, "Set to 1 to start the watchdog as"
> +MODULE_PARM_DESC(start_now, "Set to 1 to start the watchdog as "
>"soon as the driver is loaded.");
>
>   module_param(nowayout, int, 0644);


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] ipmi: reduce polling patch disrupts IPMI watchdog

[Corey Minyard]

This is almost certainly a bug in the BMC.  The change in your patch 
should have no effect, this is the start of a send, and the BMC 
interface should be idle at that point, so doing an smi_timeout will 
only result in another extraneous read from the IPMI interface (and of 
course a slightly longer delay).

I would guess that adding an extra read is working around the problem.  
Before polling was reduced, it read a whole lot more from the interface 
and probably covered the BMC bug.  You can test this by replacing that 
"smi_timeout()" added in your patch with 
"smi_info->io->inputb(smi_info->io, 1)",
which will do the read from the status register.

-corey

On 01/10/2011 06:49 PM, Brian De Wolf wrote:
> Hello, in last October I upgraded to 2.6.35 on a Sun Fire X4100 and found that
> starting the watchdog no longer worked.  It produces this output when
> started:
>
> Oct 21 15:50:14 stephen watchdog[4725]: starting daemon (5.6):
> Oct 21 15:50:14 stephen watchdog[4725]: int=30s realtime=yes sync=no soft=no 
> mla=0 mem=0
> Oct 21 15:50:14 stephen watchdog[4725]: ping: no machine to check
> Oct 21 15:50:14 stephen watchdog[4725]: file: no file to check
> Oct 21 15:50:14 stephen watchdog[4725]: pidfile: no server process to check
> Oct 21 15:50:14 stephen watchdog[4725]: interface: no interface to check
> Oct 21 15:50:14 stephen watchdog[4725]: test=none(0) repair=none 
> alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
> Oct 21 15:50:14 stephen kernel: IPMI message handler: BMC returned incorrect 
> response, expected netfn 7 cmd 22, got netfn 7 cmd 24
> Oct 21 15:50:14 stephen kernel: IPMI Watchdog: response: Error ff on cmd 22
> Oct 21 15:50:14 stephen watchdog[4725]: write watchdog device gave error 22 = 
> 'Invalid argument'!
> Oct 21 15:51:15 stephen kernel: IPMI message handler: BMC returned incorrect 
> response, expected netfn 7 cmd 35, got netfn 7 cmd 22
> Oct 21 15:51:15 stephen kernel: IPMI message handler: BMC returned incorrect 
> response, expected netfn 7 cmd 22, got netfn 7 cmd 35
>
>
> After some bisecting, I found that the patch that causes this is a
> patch to reduce ipmi polling:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3326f4f2276791561af1fd5f2020be0186459813
>
> Unfortunately, the system is unstable if I reverse this patch.  It
> crashes with "kernel BUG at kernel/timer.c:851!" (I can provide this
> output as requested)
>
>
> I originally sent this directly to Matthew Garrett but he hasn't been
> responsive for the last month or two, and I would like to eventually be
> able to upgrade to a new kernel without losing functionality.  Matthew
> provided a workaround patch, but it still produced error output
> infrequently.  He said it wasn't clean enough for upstream, but
> hopefully it will give some indication to what he found the problem to
> be:
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index e829053..3f1e856 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -316,6 +316,7 @@ static int unload_when_empty = 1;
>   static int add_smi(struct smi_info *smi);
>   static int try_smi_init(struct smi_info *smi);
>   static void cleanup_one_si(struct smi_info *to_clean);
> +static void smi_timeout(unsigned long data);
>
>   static ATOMIC_NOTIFIER_HEAD(xaction_notifier_list);
>   static int register_xaction_notifier(struct notifier_block *nb)
> @@ -896,6 +897,7 @@ static void sender(void*send_info,
>   #endif
>
>   mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
> + smi_timeout((unsigned long)smi_info);
>
>   if (smi_info->thread)
>   wake_up_process(smi_info->thread);
>
> --
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH] char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered driver

[Corey Minyard]

This patch fixes an OOPS triggered when calling modprobe ipmi_si a
second time after the first modprobe returned without finding any ipmi
devices.  This can happen if you reload the module after having the
first module load fail.  The driver was not deregistering from
PNP in that case.

Peter Huewe originally reported this patch and supplied a fix, I have
a different patch based on Linus' suggestion that cleans things up a
bit more.

KernelVersion: 2.6.37
Cc: 
Cc: 
Cc: Peter Huewe 
Cc: Randy Dunlap 
Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_si_intf.c |   12 ++--
 1 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index b6ae6e9..7855f9f 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -320,6 +320,7 @@ static int unload_when_empty = 1;
 static int add_smi(struct smi_info *smi);
 static int try_smi_init(struct smi_info *smi);
 static void cleanup_one_si(struct smi_info *to_clean);
+static void cleanup_ipmi_si(void);
 
 static ATOMIC_NOTIFIER_HEAD(xaction_notifier_list);
 static int register_xaction_notifier(struct notifier_block *nb)
@@ -3450,16 +3451,7 @@ static int __devinit init_ipmi_si(void)
mutex_lock(&smi_infos_lock);
if (unload_when_empty && list_empty(&smi_infos)) {
mutex_unlock(&smi_infos_lock);
-#ifdef CONFIG_PCI
-   if (pci_registered)
-   pci_unregister_driver(&ipmi_pci_driver);
-#endif
-
-#ifdef CONFIG_PPC_OF
-   if (of_registered)
-   of_unregister_platform_driver(&ipmi_of_platform_driver);
-#endif
-   driver_unregister(&ipmi_driver.driver);
+   cleanup_ipmi_si();
printk(KERN_WARNING PFX
   "Unable to find any System Interface(s)\n");
return -ENODEV;
-- 
1.6.3.3.333.gdf68


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [Ipmitool-devel] ipmitool breakage with kernel 2.6.37

[Corey Minyard]

This has been reported by others on different hardware, so I'm beginning 
to think this is a problem in the driver.

-corey

On 02/09/2011 07:48 AM, mika.lansiri...@stonesoft.com wrote:
> Hello,
>
> We noticed recently that ipmitool started randomly having problems when we
> upgraded the kernel from 2.6.32.(28) to 2.6.37. For example:
>
> # ipmitool sdr
> Unable to obtain SDR reservation
> Unable to open SDR for reading
>
> And at the same time dmesg was populated with these kinds of messages:
> [ 1248.568274] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
> [ 1248.570735] IPMI message handler: BMC returned incorrect response,
> expected netfn 7 cmd 35, got netfn b cmd 22
> [ 2035.155582] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
> [ 2459.722198] IPMI message handler: BMC returned incorrect response,
> expected netfn b cmd 22, got netfn b cmd 20
>
> The command was many times successful without any problems, but every now
> and then (quite often) the above problems were seen. The ipmitool used is
> from debian lenny: ipmitool version 1.8.9 and the motherboard of the
> machine is Supermicro X8DTI-F.
>
>
> As it looked like the problem is in the kernel, I started to revert
> possible commits concerning ipmi, and indeed find out that this is the one
> after which it started to fail:
>
> commit 3326f4f2276791561af1fd5f2020be0186459813
> Author: Matthew Garrett
> Date:   Wed May 26 14:43:49 2010 -0700
>
>  ipmi: reduce polling
>
>  We can reasonably alter the poll rate depending on whether we're
>  performing a transaction or merely waiting for an event.
>
>
>
> And the parts in that commit, which should be reverted to make it stable
> again are:
>
> @@ -899,13 +899,10 @@ static void sender(void*send_info,
>   printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
>   #endif
>
>   mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
>
> - if (smi_info->thread)
> - wake_up_process(smi_info->thread);
> -
>   if (smi_info->run_to_completion) {
>   /*
>* If we are running to completion, then throw it in
>* the list and run transactions until everything is
>* clear.  Priority doesn't matter here.
> @@ -1022,12 +1019,10 @@ static int ipmi_thread(void *data)
>   &busy_until);
>   if (smi_result == SI_SM_CALL_WITHOUT_DELAY)
>   ; /* do nothing */
>   else if (smi_result == SI_SM_CALL_WITH_DELAY&&  busy_wait)
>   schedule();
> - else if (smi_result == SI_SM_IDLE)
> - schedule_timeout_interruptible(100);
>   else
>   schedule_timeout_interruptible(1);
>   }
>   return 0;
>   }
>
>
>
>
> Please, let me know if you need any additional assistance regarding the
> problem.
>
>
>
> Best regards,
>   Mika Länsirinne
>
>
>
> --
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> ___
> Ipmitool-devel mailing list
> ipmitool-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel



--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] char/ipmi: cleanup_one_si section mismatch

[Corey Minyard]

Yeah, I should have noticed this.

Acked-by: Corey Minyard 

On 02/14/2011 09:03 AM, Sergey Senozhatsky wrote:
> Hello,
>
> commit d2478521afc20227658a10a8c5c2bf1a2aa615b3
> Author: Corey Minyard
> Date:   Thu Feb 10 16:08:38 2011 -0600
>
>  char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered 
> driver
>
>
> Introduced section mismatch by calling __exit cleanup_ipmi_si
> from __devinit init_ipmi_si. Should we remove __exit annotation then?
>
>
> ---
>
>   drivers/char/ipmi/ipmi_si_intf.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 7855f9f..94cd2ce 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -3532,7 +3532,7 @@ static void cleanup_one_si(struct smi_info *to_clean)
>   kfree(to_clean);
>   }
>
> -static void __exit cleanup_ipmi_si(void)
> +static void cleanup_ipmi_si(void)
>   {
>   struct smi_info *e, *tmp_e;
>
>


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] Fwd: RE: [ipmi_si_intf PATCH] based on 2.6.36 kernel

[Corey Minyard]

Let me try this again, from the proper email address so the mailing 
lists will take it.


Yichen appears to have traced this the bug down dealing with the timing 
changes that I was unable to reproduce (and i just got a Supermicro 
board, but he beat me to it).  I'm not sure this is quite the right fix, 
but it makes sense that reducing the polling might cause this problem, 
since the timeouts are not updated as regularly.


Those that have this problem, can you try this patch?

Thanks,

-corey

 Original Message 
Subject:RE: [ipmi_si_intf PATCH] based on 2.6.36 kernel
Date:   Mon, 21 Feb 2011 08:46:13 +
From:   Doe, YiCheng 
To: 	Corey Minyard , "Mingarelli, Thomas" 





Hi Corey,

The only purpose to call smi_timeout() within the sender() function is to update the 
"smi_info->last_timeout_jiffies" field to the current jiffies value.
This will prevent a very large "time_diff" value to be passed to 
smi_event_handler() in the subsequent call, which causes the send command to abort.
The state machine should be okay in this case. It is the problematic 
"time_diff" value that is causing this issue.

I hope I understand your concern correctly.
The following is the modified patch which I think should be "safer" in 
addressing this issue.

Thanks,
Yicheng




This patch fixes an issue in OpenIPMI module that sometimes an ABORT command is 
sent after
sending an IPMI request to BMC causing the IPMI request to fail.

Signed-off-by: YiCheng Doe
Acked-by: Tom Mingarelli

---

diff -rupN linux-2.6.36.2/drivers/char/ipmi/ipmi_si_intf.c 
linux-2.6.36.2p/drivers/char/ipmi/ipmi_si_intf.c
--- linux-2.6.36.2/drivers/char/ipmi/ipmi_si_intf.c 2010-12-09 
17:17:27.0 -0500
+++ linux-2.6.36.2p/drivers/char/ipmi/ipmi_si_intf.c2011-02-20 
19:15:23.475972003 -0500
@@ -899,6 +899,14 @@ static void sender(void*
printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
 #endif

+   /*
+* last_timeout_jiffies is updated here to avoid
+* smi_timeout() handler passing very large time_diff
+* value to smi_event_handler() that causes
+* the send command to abort.
+*/
+   smi_info->last_timeout_jiffies = jiffies;
+
mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);

    if (smi_info->thread)




-Original Message-
From: Corey Minyard [mailto:miny...@acm.org]
Sent: Thursday, February 17, 2011 12:11 AM
To: Mingarelli, Thomas
Cc: Doe, YiCheng
Subject: Re: [ipmi_si_intf PATCH] based on 2.6.36 kernel

I don't remember this patch.  And I doubt this is the right solution.
If the sender function is called, the state machine better be idle.  And
SMI timeout might start a receive operation if something is pending,
which will break the send.

Maybe there is something missing at the end of the state machine that
cleans things up properly.  That's the place to look, I think.

-corey

On 02/16/2011 08:32 AM, Mingarelli, Thomas wrote:

 Hello Corey:


 Is there any update on the patch below being accepted or not?


 Thanks,
 Tom

 -Original Message-
 From: Mingarelli, Thomas
 Sent: Friday, January 14, 2011 11:01 AM
 To: miny...@acm.org
 Cc: Mingarelli, Thomas; Doe, YiCheng
 Subject: [ipmi_si_intf PATCH] based on 2.6.36 kernel

 This patch fixes an issue in OpenIPMI module that sometimes an ABORT command 
is sent after
 sending an IPMI request to BMC causing the IPMI request to fail.

 Signed-off-by: YiCheng Doe
 Acked-by: Tom Mingarelli

 ---

 diff -rupN linux-2.6.36.2/drivers/char/ipmi/ipmi_si_intf.c 
linux-2.6.36.2p/drivers/char/ipmi/ipmi_si_intf.c
 --- linux-2.6.36.2/drivers/char/ipmi/ipmi_si_intf.c2010-12-09 
17:17:27.0 -0500
 +++ linux-2.6.36.2p/drivers/char/ipmi/ipmi_si_intf.c   2011-01-03 
21:00:31.088841833 -0500
 @@ -320,6 +320,7 @@ static int unload_when_empty = 1;
   static int add_smi(struct smi_info *smi);
   static int try_smi_init(struct smi_info *smi);
   static void cleanup_one_si(struct smi_info *to_clean);
 +static void smi_timeout(unsigned long data);

   static ATOMIC_NOTIFIER_HEAD(xaction_notifier_list);
   static int register_xaction_notifier(struct notifier_block *nb)
 @@ -900,6 +901,7 @@ static void sender(void*
   #endif

mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
 +  smi_timeout((unsigned long)smi_info);

if (smi_info->thread)
wake_up_process(smi_info->thread);



--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splun

Re: [Openipmi-developer] OpenIPMI and CPU temperature

[Corey Minyard]

On 02/24/2011 09:49 AM, Sandra Escandor wrote:


Hello,

I'm currently researching how to use OpenIPMI to obtain sensor 
readings, specifically for an Intel Xeon 5500 CPU. I am wondering: Is 
it possible to obtain this reading through OpenIPMI, or should I use 
something else?


One of the reasons why I ask this is, from what I've found out, the 
temperature of the CPU can be read from an MSR -- does the BMC get 
access to this, so that I can eventually use OpenIPMI to obtain this 
reading? Also, when I use ipmitool, the CPU temperature reading that I 
get is " 0 unspecified" -- this tells me that the SDR doesn't have a 
temperature reading (unless I need some extra driver specific for 
this?). Please correct me if I'm wrong -- I've only started looking 
over the IPMI concepts.


Thanks for your help,

Sandra


I'm not quite sure what the hardware is capable of doing.  The BMC can't 
get the data directly from an MSR, of course, and I'm not sure if 
there's another way for the BMC to fetch this information.  I have some 
systems that do and some that don't.  It depends on your board.


OpenIPMI is just a conveyor of information.  The board manufacturer has 
to put the information in for it to transfer the information.  I don't 
think you need an extra driver to get any information to the BMC, but 
you might need for the system to be on for it to work.  I have a system 
with processor temperature, but you have to turn the system on to get a 
reading.


-corey
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: Fix IPMI errors due to timing problems

[Corey Minyard]

On 03/10/2011 01:17 PM, Matthew Garrett wrote:
> On Thu, Mar 10, 2011 at 01:12:50PM -0600, Corey Minyard wrote:
>
>> +smi_info->last_timeout_jiffies ?iffies;
> Something looks mangled here? Otherwise, ACK.
>
I have no idea how that happened, but it wasn't that way before I 
compiled with it.  I guess I'll resend.

-corey

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH] ipmi: Fix IPMI errors due to timing problems

[Corey Minyard]

From: Doe, YiCheng 

This patch fixes an issue in OpenIPMI module where sometimes an ABORT command
is sent after sending an IPMI request to BMC causing the IPMI request to fail.

Signed-off-by: YiCheng Doe 
Signed-off-by: Corey Minyard 
Acked-by: Tom Mingarelli 
Tested-by: Andy Cress 
Tested-by: Mika Lansirine 
Tested-by: Brian De Wolf 
Cc: Jean Michel Audet 
Cc: Jozef Sudelsky 
Cc: Matthew Garrett 
---
 drivers/char/ipmi/ipmi_si_intf.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 7855f9f..62787e3 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -900,6 +900,14 @@ static void sender(void*send_info,
printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
 #endif
 
+   /*
+* last_timeout_jiffies is updated here to avoid
+* smi_timeout() handler passing very large time_diff
+* value to smi_event_handler() that causes
+* the send command to abort.
+*/
+   smi_info->last_timeout_jiffies = jiffies;
+
mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
 
if (smi_info->thread)
-- 
1.7.1


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH] ipmi: Fix IPMI errors due to timing problems

[Corey Minyard]

From: Doe, YiCheng 

This patch fixes an issue in OpenIPMI module where sometimes an ABORT command
is sent after sending an IPMI request to BMC causing the IPMI request to fail.

Signed-off-by: YiCheng Doe 
Signed-off-by: Corey Minyard 
Acked-by: Tom Mingarelli 
Tested-by: Andy Cress 
Tested-by: Mika Lansirine 
Tested-by: Brian De Wolf 
Cc: Jean Michel Audet 
Cc: Jozef Sudelsky 
Cc: Matthew Garrett 
---
 drivers/char/ipmi/ipmi_si_intf.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 7855f9f..5b88096 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -900,6 +900,14 @@ static void sender(void*send_info,
printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
 #endif
 
+   /*
+* last_timeout_jiffies is updated here to avoid
+* smi_timeout() handler passing very large time_diff
+* value to smi_event_handler() that causes
+* the send command to abort.
+*/
+   smi_info->last_timeout_jiffies ÿiffies;
+
mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
 
if (smi_info->thread)
-- 
1.7.1



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] How to compiled openipmi-python module

[Corey Minyard]

It should work automatically.  Do you have python-dev installed?

On Apr 16, 2011 11:08 PM, "白白wong"  wrote:

HI~

   Who can provide the way to  compiled openipmi-python module ?
   when compiled OpenIPMI i give the
"--with-python=/usr/bin/python2.5
--with-pythoninstall=/usr/lib/python2.5/site-packages" but it don't
work .

   thanks all~~


Nothing is Sound.

--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] OpenIPMI and RedHat 6

[Corey Minyard]

Well, first of all, ipmitool is not part of the openipmi package, it is 
a separate tool.  But it's probably what you want.

You probably don't have the IPMI driver loaded or your board does not 
have IPMI support.  IIRC, RHEL 6 should automatically load the driver, 
so my suspicion is the latter.  You can try to "modprobe ipmi_si" and 
look in /proc/ipmi.  You should see "0" (for interface zero) there if it 
work.  If that works, "modprobe ipmi_devintf" for to get the device 
interface and you should be good to go.

If not, and if you are sure you have a board with IPMI support, it might 
have a serial or SMB interface.  You will require kernel patches for 
that to work.

If your board has a system interface supported by the standard kernel, 
then there may be a bug someplace, either in the driver or in the interface.

If you don't have IPMI support, you can probably still get to the 
temperature sensors via I2C.

-corey

On 07/28/2011 11:02 AM, Bob Sauvage wrote:
> Hello *
>
> New to IPMI world, I want to get info about fans and temperatures of my
> server.
>
> My server is running under RHEL 6 with this kernel :
> /2.6.32-131.6.1.el6.x86_64./
>
> I installed this OpenIPMI package : /OpenIPMI.x86_64 2.0.16-12.el6/ and
> this ipmitool package : /ipmitool.x86_64 1.8.11-7.el6/.
>
> But when I launch this command, it fails :
>
> /ipmitool sel list
> Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No
> such file or directory
> Get SEL Info command failed/
>
> It seems that the driver is not correctly binded to the device ?
>
> Someone can help me ?
>
> Thanks a lot !
>
> --
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] OpenIPMI and RedHat 6

[Corey Minyard]

On 07/29/2011 03:50 AM, Bob Sauvage wrote:

Hello Jan and Corey,

First of all, thanks for the provided information.

The ipmi service is started :

*service ipmi status*

ipmi_msghandler module loaded.
ipmi_si module loaded.
ipmi_devintf module loaded.
/dev/ipmi0 does not exist.

*Modules are loaded : *

Module  Size  Used by
ipmi_devintf7983  0
ipmi_si42399  0
ipmi_msghandler35958  2 ipmi_devintf,ipmi_si

*dmidecode :*

System Information
Manufacturer: Supermicro
Product Name: X8SIL

IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x00
NV Storage Device: Not Present
Base Address: 0x0CA2 (Memory-mapped)
Register Spacing: Successive Byte Boundaries

*Kernel log : *

jul 29 10:39:32  kernel: ipmi message handler version 39.2
Jul 29 10:39:32  kernel: IPMI System Interface driver.
Jul 29 10:39:32  kernel: ipmi_si: Adding SMBIOS-specified kcs state 
machine
Jul 29 10:39:32  kernel: ipmi_si: Trying SMBIOS-specified kcs state 
machine at mem address 0xca2, slave address 0x0, irq 0

Jul 29 10:39:32  kernel: Could not set up I/O space
This is the issue.  It looks like a bug in your DMI information.  Notice 
that it say the address is 0xca2 and it is memory mapped.  That is 
almost certainly wrong, as you would never have a memory mapped device 
at that address.  It's almost certainly I/O mapped.


You can attempt to work around this by specifying "type=kcs ports=0xca2" 
when modprob-ing ipmi_si:


   rmmod ipmi_si
   modprobe ipmi_si type=kcs ports=0xca2

Alternately, you can hot-add the device to the running driver using:

   echo "add,kcs,i/o,0xca2" >/sys/module/ipmi_si/parameters/hotmod

And of course, you can complain to your motherboard vendor.

-corey
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 31/62] driver/char: irq: Remove IRQF_DISABLED

[Corey Minyard]

On 09/07/2011 03:10 AM, Yong Zhang wrote:
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 9397ab4..44e8da3 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1336,7 +1336,7 @@ static int std_irq_setup(struct smi_info *info)
>   if (info->si_type == SI_BT) {
>   rv = request_irq(info->irq,
>si_bt_irq_handler,
> -  IRQF_SHARED | IRQF_DISABLED,
> +  IRQF_SHARED,
>DEVICE_NAME,
>info);
>   if (!rv)
> @@ -1346,7 +1346,7 @@ static int std_irq_setup(struct smi_info *info)
>   } else
>   rv = request_irq(info->irq,
>si_irq_handler,
> -  IRQF_SHARED | IRQF_DISABLED,
> +  IRQF_SHARED,
>DEVICE_NAME,
>        info);
>   if (rv) {
>
Ok by me.

Acked-by: Corey Minyard 

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] openipmi appropriateness for raw requests

[Corey Minyard]

On 10/11/2011 04:02 PM, a...@nyi.net wrote:

  So I have some ipmitool raw commands i run remotely against a host's
  bmc, and wanted to code them via the python bindings (so i can more
  frequent polling and then do further processing w/o forking ipmitool
  over and over).

  However the documentation is a bit sparse and i can't honestly see how
  do i construct some code to do this?

  So i have to ask, is emulating raw requests something viable via
  OpenIPMI? Is there any examples i can look at ? Even if it's just in C,
  i figure the python bindings are pretty thinly swig'ified, but if i
  could figure out if/how that's done, i'll tackle pythonifying it
  afterwards.


Sure, that's easy.  There is a file named "swig/python/sample.py" that 
has a sample of a python interface.I've also attached a little 
program that does a get device id command every 5 seconds.  Run it with 
"sample2.py smi 0" to talk to the local interface.


What are you trying to get, btw?  OpenIPMI can do most of the 
interpretation work for you.


-corey
import time
import sys
import OpenIPMI

class Handlers:
def __init__(self, name):
self.name = name
self.mc = None
return

def log(self, level, log):
	print level + ": " + log
return

def conn_change_cb(self, domain, err, conn_num, port_num, still_connected):
print "Conn up"
return

def domain_close_done_cb(self):
	self.name = "done"
return

def domain_iter_mc_cb(self, domain, mc):
print "MC: " + mc.get_name()
if mc.get_name() == "test(0.20)":
# This is the one we want
self.mc = mc.get_id();
return

# This is here due to a bug in the swig interface, it will go away in
# the next release.  It doesn't actually do anything.
def mc_iter_cb(self, domain, mc):
print "MC2: " + mc.get_name()
return

def domain_up_cb(self, domain):
	domain.iterate_mcs(self)
return

def mc_cmd_cb(self, mc, netfn, cmd, response):
print "got response: " + str(response)
return

def mc_cb(self, mc):
mc.send_command(0, 6, 1, [], self)
return

OpenIPMI.enable_debug_malloc()
OpenIPMI.init_posix()

main_handler = Handlers("hello")

OpenIPMI.set_log_handler(main_handler)

a = OpenIPMI.open_domain2("test", ["-noall",] + sys.argv[1:],
  main_handler, main_handler)
if not a:
print "open failed"
sys.exit(1)
pass

nexttime = time.time()
while main_handler.name != "done":
OpenIPMI.wait_io(1000)
now = time.time()
if main_handler.mc and now >= nexttime:
nexttime += 5
main_handler.mc.to_mc(main_handler)
pass

OpenIPMI.shutdown_everything()
print "done"
sys.exit(0)
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] Version 2.0.19 of OpenIPMI uploaded

[Corey Minyard]

It's been a long time since I uploaded a version of OpenIPMI, and there 
are some little bug fixes pending.  Most of the changes are due to 
autotools changes, though I found a couple of little bugs today playing 
with the python script I just sent out.

-corey

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] openipmi appropriateness for raw requests

[Corey Minyard]

On 10/12/2011 11:28 AM, a...@nyi.net wrote:
> Thanks, I've looked at the sample.py a few times already but i 
> couldn't get it to run in our environment (the GUI encumberance keeps 
> it from running in our environment) and hence it was a little 
> difficult to get my head wrapped around the code itself if i couldn't 
> see it in action.  This is on top of there not seeming to be much 
> documentation on the different function calls, other than looking at 
> the source code for the swig interface (the .i file) or the lib's c code
>
> i'll take a look at the the program you attached too, but basically 
> what i'm trying to do is query power data against an HP sl-line of 
> systems that don't have full-blown iLO's (the cheaper SL systems had a 
> less capable lo100, like the sl160z g6 or the sl165s g7) which 
> originally made power-monitoring difficult and limited via an HP tool 
> that only runs locally.  But I've discovered the utility they use 
> locally to query the data from the (sl6000/sl6500) chassis the systems 
> are in, uses ipmi raw under the hood, and these ipmi raw queries work 
> remotely against the bmc of the host as well.  i was hoping to have 
> something that can frequently poll power usage out-of-band (since the 
> readings appear to be instantaneous and not averaged over an interval) 
> while we are doing benchmarking against new procs from AMD (hence i 
> don't want to run the utility HP provides locally since that will take 
> away CPU time from the benchmarks).
>
> my C is really not that strong but i've getting a good grasp on python 
> lately (been using perl for a while now as well), hence i was trying 
> to get more familiar with OO/python and use OpenIPMI, but from what 
> i've seen, OpenIPMI seems to want to do all this leg work for you that 
> i'm not sure i need, and i'm not sure how to just have it do something 
> low-level/simple like connect to a bmc, authenticate, start a session, 
> and with the same session poll a raw cmd against the bmc every few 
> seconds (or more frequently depending on the resolution of the data 
> being returned).
The sample2.py code I sent in the previous email should show how to do this.

>
> the limited amount of example code i had see of OpenIPMI get 
> incredibly complex really fast (esp when GUI functionality is 
> entangled into the code IMO needlessly).  i just want to do something 
> simple like throw some raw hex queries (netfn/cmd/data) at a bmc and 
> get the data back as quickly as possible.. hopefully w/o forking a 
> separate helper command to do it (e.g. ipmitool or ipmiutil).. and i 
> was hoping OpenIPMI could spare me having to re-invent the lower 
> framework of crafting udp packets and stuffing them with 
> ipmi-compatible data just to do a simple ipmi-raw query :-\ but it 
> started to seem like OpenIPMI wasn't intended for this use, but 
> instead to help write more complex management software suites (with 
> OpenIPMI handling the complicated tasks).  Hence my original question 
> to this list if OpenIPMI is too powerful a tool for my simple needs :)

There is no GUI code entangled in the OpenIPMI python interface, nor in 
the sample.py script.  It is fairly entangled with the openipmi GUI, 
obviously, perhaps you were looking there.

OpenIPMI was intended to be able to do simple things, too, but it's a 
huge interface and there's not much documentation help for writing 
simple things.

>
> I was hoping someone had some simple sample code that took a 
> username/password/ip for the bmc, and i could hard-code the hex 
> queries into the code and adapt it to the rest of my needs.

The "sample2.py" program I sent you will work for lan interfaces, too.  
Run it as:

sample2.py lan -U  -P  

You can obviously hard-code those values in the program, if you like.

-corey

>
> On Wed, 12 Oct 2011 10:02:16 -0500, Corey Minyard wrote:
>> On 10/11/2011 04:02 PM, a...@nyi.net wrote:
>>>   So I have some ipmitool raw commands i run remotely against a host's
>>>   bmc, and wanted to code them via the python bindings (so i can more
>>>   frequent polling and then do further processing w/o forking ipmitool
>>>   over and over).
>>>
>>>   However the documentation is a bit sparse and i can't honestly see 
>>> how
>>>   do i construct some code to do this?
>>>
>>>   So i have to ask, is emulating raw requests something viable via
>>>   OpenIPMI? Is there any examples i can look at ? Even if it's just 
>>> in C,
>>>   i figure the python bindings are pretty thinly swig'ified, but if i
>>>   could figure out if/how that's done, i'll ta

Re: [Openipmi-developer] [PATCH] ipmi: Increase KCS timeouts

[Corey Minyard]

This is fine, if it is really necessary to make slow hardware work.  
I've pulled it in, I'll submit in a bit.

-corey

On 12/14/2011 03:12 PM, Matthew Garrett wrote:
> Ping?
>
> On Wed, Nov 30, 2011 at 02:12:27PM -0500, Matthew Garrett wrote:
>> We currently time out and retry KCS transactions after 1 second of waiting
>> for IBF or OBF. This appears to be too short for some hardware. The IPMI
>> spec says "All system software wait loops should include error timeouts. For
>> simplicity, such timeouts are not shown explicitly in the flow diagrams. A
>> five-second timeout or greater is recommended". Change the timeout to five
>> seconds to satisfy the slow hardware.
>>
>> Signed-off-by: Matthew Garrett
>> ---
>>   drivers/char/ipmi/ipmi_kcs_sm.c |4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c 
>> b/drivers/char/ipmi/ipmi_kcs_sm.c
>> index cf82fed..e53fc24 100644
>> --- a/drivers/char/ipmi/ipmi_kcs_sm.c
>> +++ b/drivers/char/ipmi/ipmi_kcs_sm.c
>> @@ -118,8 +118,8 @@ enum kcs_states {
>>   #define MAX_KCS_WRITE_SIZE IPMI_MAX_MSG_LENGTH
>>
>>   /* Timeouts in microseconds. */
>> -#define IBF_RETRY_TIMEOUT 100
>> -#define OBF_RETRY_TIMEOUT 100
>> +#define IBF_RETRY_TIMEOUT 500
>> +#define OBF_RETRY_TIMEOUT 500
>>   #define MAX_ERROR_RETRIES 10
>>   #define ERROR0_OBF_WAIT_JIFFIES (2*HZ)
>>
>> -- 
>> 1.7.7.1
>>
>>


--
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 2/6] ipmi: Increase KCS timeouts

[Corey Minyard]

From: Matthew Garrett 

We currently time out and retry KCS transactions after 1 second of waiting
for IBF or OBF. This appears to be too short for some hardware. The IPMI
spec says "All system software wait loops should include error timeouts. For
simplicity, such timeouts are not shown explicitly in the flow diagrams. A
five-second timeout or greater is recommended". Change the timeout to five
seconds to satisfy the slow hardware.

From: Matthew Garrett 
Signed-off-by: Matthew Garrett 
Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_kcs_sm.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c b/drivers/char/ipmi/ipmi_kcs_sm.c
index cf82fed..e53fc24 100644
--- a/drivers/char/ipmi/ipmi_kcs_sm.c
+++ b/drivers/char/ipmi/ipmi_kcs_sm.c
@@ -118,8 +118,8 @@ enum kcs_states {
 #define MAX_KCS_WRITE_SIZE IPMI_MAX_MSG_LENGTH
 
 /* Timeouts in microseconds. */
-#define IBF_RETRY_TIMEOUT 100
-#define OBF_RETRY_TIMEOUT 100
+#define IBF_RETRY_TIMEOUT 500
+#define OBF_RETRY_TIMEOUT 500
 #define MAX_ERROR_RETRIES 10
 #define ERROR0_OBF_WAIT_JIFFIES (2*HZ)
 
-- 
1.7.4.1


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 4/6] ipmi: Fix message handling during panics

[Corey Minyard]

The part of the IPMI driver that delivered panic information to the
event log and extended the watchdog timeout during a panic was not
properly handling the messages.  It used static messages to avoid
allocation, but wasn't properly waiting for these, or wasn't properly
handling the refcounts.

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_msghandler.c |  103 ---
 drivers/char/ipmi/ipmi_watchdog.c   |   17 ---
 2 files changed, 56 insertions(+), 64 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 289ab50..5c1820c 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2794,16 +2794,18 @@ channel_handler(ipmi_smi_t intf, struct ipmi_recv_msg 
*msg)
return;
 }
 
-void ipmi_poll_interface(ipmi_user_t user)
+static void ipmi_poll(ipmi_smi_t intf)
 {
-   ipmi_smi_t intf = user->intf;
-
if (intf->handlers->poll)
intf->handlers->poll(intf->send_info);
-
/* In case something came in */
handle_new_recv_msgs(intf);
 }
+
+void ipmi_poll_interface(ipmi_user_t user)
+{
+   ipmi_poll(user->intf);
+}
 EXPORT_SYMBOL(ipmi_poll_interface);
 
 int ipmi_register_smi(struct ipmi_smi_handlers *handlers,
@@ -4204,12 +4206,48 @@ EXPORT_SYMBOL(ipmi_free_recv_msg);
 
 #ifdef CONFIG_IPMI_PANIC_EVENT
 
+static atomic_t panic_done_count = ATOMIC_INIT(0);
+
 static void dummy_smi_done_handler(struct ipmi_smi_msg *msg)
 {
+   atomic_dec(&panic_done_count);
 }
 
 static void dummy_recv_done_handler(struct ipmi_recv_msg *msg)
 {
+   atomic_dec(&panic_done_count);
+}
+
+/*
+ * Inside a panic, send a message and wait for a response.
+ */
+static void ipmi_panic_request_and_wait(ipmi_smi_t   intf,
+   struct ipmi_addr *addr,
+   struct kernel_ipmi_msg *msg)
+{
+   struct ipmi_smi_msg  smi_msg;
+   struct ipmi_recv_msg recv_msg;
+   int rv;
+
+   smi_msg.done = dummy_smi_done_handler;
+   recv_msg.done = dummy_recv_done_handler;
+   atomic_add(2, &panic_done_count);
+   rv = i_ipmi_request(NULL,
+   intf,
+   addr,
+   0,
+   msg,
+   intf,
+   &smi_msg,
+   &recv_msg,
+   0,
+   intf->channels[0].address,
+   intf->channels[0].lun,
+   0, 1); /* Don't retry, and don't wait. */
+   if (rv)
+   atomic_sub(2, &panic_done_count);
+   while (atomic_read(&panic_done_count) != 0)
+   ipmi_poll(intf);
 }
 
 #ifdef CONFIG_IPMI_PANIC_STRING
@@ -4248,8 +4286,6 @@ static void send_panic_events(char *str)
unsigned char data[16];
struct ipmi_system_interface_addr *si;
struct ipmi_addr  addr;
-   struct ipmi_smi_msg   smi_msg;
-   struct ipmi_recv_msg  recv_msg;
 
si = (struct ipmi_system_interface_addr *) &addr;
si->addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
@@ -4277,9 +4313,6 @@ static void send_panic_events(char *str)
data[7] = str[2];
}
 
-   smi_msg.done = dummy_smi_done_handler;
-   recv_msg.done = dummy_recv_done_handler;
-
/* For every registered interface, send the event. */
list_for_each_entry_rcu(intf, &ipmi_interfaces, link) {
if (!intf->handlers)
@@ -4289,18 +4322,7 @@ static void send_panic_events(char *str)
intf->run_to_completion = 1;
/* Send the event announcing the panic. */
intf->handlers->set_run_to_completion(intf->send_info, 1);
-   i_ipmi_request(NULL,
-  intf,
-  &addr,
-  0,
-  &msg,
-  intf,
-  &smi_msg,
-  &recv_msg,
-  0,
-  intf->channels[0].address,
-  intf->channels[0].lun,
-  0, 1); /* Don't retry, and don't wait. */
+   ipmi_panic_request_and_wait(intf, &addr, &msg);
}
 
 #ifdef CONFIG_IPMI_PANIC_STRING
@@ -4348,18 +4370,7 @@ static void send_panic_events(char *str)
msg.data = NULL;
msg.data_len = 0;
intf->null_user_handler = device_id_fetcher;
-   i_ipmi_request(NULL,
-  intf,
-  &addr,

[Openipmi-developer] [PATCH 5/6] ipmi: Simplify locking

[Corey Minyard]

Now that the the IPMI driver is using a tasklet, we can simplify
the locking in the driver and get rid of the message lock.

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_si_intf.c |   54 ++---
 1 files changed, 21 insertions(+), 33 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 01e53cd..3c7e693 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -171,7 +171,6 @@ struct smi_info {
struct si_sm_handlers  *handlers;
enum si_type   si_type;
spinlock_t si_lock;
-   spinlock_t msg_lock;
struct list_head   xmit_msgs;
struct list_head   hp_xmit_msgs;
struct ipmi_smi_msg*curr_msg;
@@ -350,13 +349,6 @@ static enum si_sm_result start_next_msg(struct smi_info 
*smi_info)
struct timeval t;
 #endif
 
-   /*
-* No need to save flags, we aleady have interrupts off and we
-* already hold the SMI lock.
-*/
-   if (!smi_info->run_to_completion)
-   spin_lock(&(smi_info->msg_lock));
-
/* Pick the high priority queue first. */
if (!list_empty(&(smi_info->hp_xmit_msgs))) {
entry = smi_info->hp_xmit_msgs.next;
@@ -394,9 +386,6 @@ static enum si_sm_result start_next_msg(struct smi_info 
*smi_info)
rv = SI_SM_CALL_WITHOUT_DELAY;
}
  out:
-   if (!smi_info->run_to_completion)
-   spin_unlock(&(smi_info->msg_lock));
-
return rv;
 }
 
@@ -879,19 +868,6 @@ static void sender(void*send_info,
printk("**Enqueue: %d.%9.9d\n", t.tv_sec, t.tv_usec);
 #endif
 
-   /*
-* last_timeout_jiffies is updated here to avoid
-* smi_timeout() handler passing very large time_diff
-* value to smi_event_handler() that causes
-* the send command to abort.
-*/
-   smi_info->last_timeout_jiffies = jiffies;
-
-   mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
-
-   if (smi_info->thread)
-   wake_up_process(smi_info->thread);
-
if (smi_info->run_to_completion) {
/*
 * If we are running to completion, then throw it in
@@ -914,15 +890,26 @@ static void sender(void*send_info,
return;
}
 
-   spin_lock_irqsave(&smi_info->msg_lock, flags);
+   spin_lock_irqsave(&smi_info->si_lock, flags);
if (priority > 0)
list_add_tail(&msg->link, &smi_info->hp_xmit_msgs);
else
list_add_tail(&msg->link, &smi_info->xmit_msgs);
-   spin_unlock_irqrestore(&smi_info->msg_lock, flags);
 
-   spin_lock_irqsave(&smi_info->si_lock, flags);
if (smi_info->si_state == SI_NORMAL && smi_info->curr_msg == NULL) {
+   /*
+* last_timeout_jiffies is updated here to avoid
+* smi_timeout() handler passing very large time_diff
+* value to smi_event_handler() that causes
+* the send command to abort.
+*/
+   smi_info->last_timeout_jiffies = jiffies;
+
+   mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
+
+   if (smi_info->thread)
+   wake_up_process(smi_info->thread);
+
start_next_msg(smi_info);
smi_event_handler(smi_info, 0);
}
@@ -1026,16 +1013,19 @@ static int ipmi_thread(void *data)
 static void poll(void *send_info)
 {
struct smi_info *smi_info = send_info;
-   unsigned long flags;
+   unsigned long flags = 0;
+   int run_to_completion = smi_info->run_to_completion;
 
/*
 * Make sure there is some delay in the poll loop so we can
 * drive time forward and timeout things.
 */
udelay(10);
-   spin_lock_irqsave(&smi_info->si_lock, flags);
+   if (!run_to_completion)
+   spin_lock_irqsave(&smi_info->si_lock, flags);
smi_event_handler(smi_info, 10);
-   spin_unlock_irqrestore(&smi_info->si_lock, flags);
+   if (!run_to_completion)
+   spin_unlock_irqrestore(&smi_info->si_lock, flags);
 }
 
 static void request_events(void *send_info)
@@ -1672,10 +1662,8 @@ static struct smi_info *smi_info_alloc(void)
 {
struct smi_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
 
-   if (info) {
+   if (info)
spin_lock_init(&info->si_lock);
-   spin_lock_init(&info->msg_lock);
-   }
return info;
 }
 
-- 
1.7.4.1


--
Try before you buy = See our experts in action!
The most comprehens

[Openipmi-developer] [PATCH 3/6] ipmi: use a tasklet for handling received messages

[Corey Minyard]

The IPMI driver would release a lock, deliver a message, then relock.
This is obviously ugly, and this patch converts the message handler
interface to use a tasklet to schedule work.  This lets the receive
handler be called from an interrupt handler with interrupts enabled.

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_msghandler.c |  141 +--
 drivers/char/ipmi/ipmi_si_intf.c|   14 +---
 2 files changed, 88 insertions(+), 67 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 58c0e63..289ab50 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PFX "IPMI message handler: "
 
@@ -53,6 +54,8 @@
 
 static struct ipmi_recv_msg *ipmi_alloc_recv_msg(void);
 static int ipmi_init_msghandler(void);
+static void smi_recv_tasklet(unsigned long);
+static void handle_new_recv_msgs(ipmi_smi_t intf);
 
 static int initialized;
 
@@ -355,12 +358,15 @@ struct ipmi_smi {
int curr_seq;
 
/*
-* Messages that were delayed for some reason (out of memory,
-* for instance), will go in here to be processed later in a
-* periodic timer interrupt.
+* Messages queued for delivery.  If delivery fails (out of memory
+* for instance), They will stay in here to be processed later in a
+* periodic timer interrupt.  The tasklet is for handling received
+* messages directly from the handler.
 */
spinlock_t   waiting_msgs_lock;
struct list_head waiting_msgs;
+   atomic_t watchdog_pretimeouts_to_deliver;
+   struct tasklet_struct recv_tasklet;
 
/*
 * The list of command receivers that are registered for commands
@@ -493,6 +499,8 @@ static void clean_up_interface_data(ipmi_smi_t intf)
struct cmd_rcvr  *rcvr, *rcvr2;
struct list_head list;
 
+   tasklet_kill(&intf->recv_tasklet);
+
free_smi_msg_list(&intf->waiting_msgs);
free_recv_msg_list(&intf->waiting_events);
 
@@ -2792,6 +2800,9 @@ void ipmi_poll_interface(ipmi_user_t user)
 
if (intf->handlers->poll)
intf->handlers->poll(intf->send_info);
+
+   /* In case something came in */
+   handle_new_recv_msgs(intf);
 }
 EXPORT_SYMBOL(ipmi_poll_interface);
 
@@ -2860,6 +2871,10 @@ int ipmi_register_smi(struct ipmi_smi_handlers *handlers,
 #endif
spin_lock_init(&intf->waiting_msgs_lock);
INIT_LIST_HEAD(&intf->waiting_msgs);
+   tasklet_init(&intf->recv_tasklet,
+smi_recv_tasklet,
+(unsigned long) intf);
+   atomic_set(&intf->watchdog_pretimeouts_to_deliver, 0);
spin_lock_init(&intf->events_lock);
INIT_LIST_HEAD(&intf->waiting_events);
intf->waiting_events_count = 0;
@@ -3622,11 +3637,11 @@ static int handle_bmc_rsp(ipmi_smi_t  intf,
 }
 
 /*
- * Handle a new message.  Return 1 if the message should be requeued,
+ * Handle a received message.  Return 1 if the message should be requeued,
  * 0 if the message should be freed, or -1 if the message should not
  * be freed or requeued.
  */
-static int handle_new_recv_msg(ipmi_smi_t  intf,
+static int handle_one_recv_msg(ipmi_smi_t  intf,
   struct ipmi_smi_msg *msg)
 {
int requeue;
@@ -3784,12 +3799,72 @@ static int handle_new_recv_msg(ipmi_smi_t  intf,
return requeue;
 }
 
+/*
+ * If there are messages in the queue or pretimeouts, handle them.
+ */
+static void handle_new_recv_msgs(ipmi_smi_t intf)
+{
+   struct ipmi_smi_msg  *smi_msg;
+   unsigned longflags = 0;
+   int  rv;
+   int  run_to_completion = intf->run_to_completion;
+
+   /* See if any waiting messages need to be processed. */
+   if (!run_to_completion)
+   spin_lock_irqsave(&intf->waiting_msgs_lock, flags);
+   while (!list_empty(&intf->waiting_msgs)) {
+   smi_msg = list_entry(intf->waiting_msgs.next,
+struct ipmi_smi_msg, link);
+   list_del(&smi_msg->link);
+   if (!run_to_completion)
+   spin_unlock_irqrestore(&intf->waiting_msgs_lock, flags);
+   rv = handle_one_recv_msg(intf, smi_msg);
+   if (!run_to_completion)
+   spin_lock_irqsave(&intf->waiting_msgs_lock, flags);
+   if (rv == 0) {
+   /* Message handled */
+   ipmi_free_smi_msg(smi_msg);
+   } else if (rv < 0) {
+   /* Fatal error on the message, del but don't free. */
+   } else {
+

[Openipmi-developer] [PATCH 6/6] ipmi: Use locks on watchdog timeout set on reboot

[Corey Minyard]

The IPMI watchdog timer clears or extends the timer on reboot/shutdown.
It was using the non-locking routine for setting the watchdog timer, but
this was causing race conditions.  Instead, use the locking version to
avoid the races.  It seems to work fine.

Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_watchdog.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_watchdog.c 
b/drivers/char/ipmi/ipmi_watchdog.c
index 57a53ba..99dc1da 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -1167,7 +1167,7 @@ static int wdog_reboot_handler(struct notifier_block 
*this,
if (code == SYS_POWER_OFF || code == SYS_HALT) {
/* Disable the WDT if we are shutting down. */
ipmi_watchdog_state = WDOG_TIMEOUT_NONE;
-   panic_halt_ipmi_set_timeout();
+   ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB);
} else if (ipmi_watchdog_state != WDOG_TIMEOUT_NONE) {
/* Set a long timer to let the reboot happens, but
   reboot if it hangs, but only if the watchdog
@@ -1175,7 +1175,7 @@ static int wdog_reboot_handler(struct notifier_block 
*this,
timeout = 120;
pretimeout = 0;
ipmi_watchdog_state = WDOG_TIMEOUT_RESET;
-   panic_halt_ipmi_set_timeout();
+   ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB);
}
}
return NOTIFY_OK;
-- 
1.7.4.1


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 1/6] ipmi: decreases the IPMI message transaction time in interrupt mode

[Corey Minyard]

From: Srinivas_Gowda 

Call the event handler immediately after starting the next message.

This change considerably decreases the IPMI transaction time (cuts off
~9ms for a single ipmitool transaction).

From: Srinivas_Gowda 
Signed-off-by: Srinivas_Gowda 
Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_si_intf.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 50fcf9c..73ebbb1 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -932,8 +932,10 @@ static void sender(void*send_info,
spin_unlock_irqrestore(&smi_info->msg_lock, flags);
 
spin_lock_irqsave(&smi_info->si_lock, flags);
-   if (smi_info->si_state == SI_NORMAL && smi_info->curr_msg == NULL)
+   if (smi_info->si_state == SI_NORMAL && smi_info->curr_msg == NULL) {
start_next_msg(smi_info);
+   smi_event_handler(smi_info, 0);
+   }
spin_unlock_irqrestore(&smi_info->si_lock, flags);
 }
 
-- 
1.7.4.1


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 3/6] ipmi: use a tasklet for handling received messages

[Corey Minyard]

On 02/03/2012 01:44 PM, Andrew Morton wrote:
> On Fri, 03 Feb 2012 09:47:56 -0600
> Corey Minyard  wrote:
>
>> The IPMI driver would release a lock, deliver a message, then relock.
>> This is obviously ugly, and this patch converts the message handler
>> interface to use a tasklet to schedule work.  This lets the receive
>> handler be called from an interrupt handler with interrupts enabled.
>>
>> ...
>>
>> +/*
>> + * If there are messages in the queue or pretimeouts, handle them.
>> + */
>> +static void handle_new_recv_msgs(ipmi_smi_t intf)
>> +{
>> +struct ipmi_smi_msg  *smi_msg;
>> +unsigned longflags = 0;
>> +int  rv;
>> +int  run_to_completion = intf->run_to_completion;
>> +
>> +/* See if any waiting messages need to be processed. */
>> +if (!run_to_completion)
>> +spin_lock_irqsave(&intf->waiting_msgs_lock, flags);
>> +while (!list_empty(&intf->waiting_msgs)) {
>> +smi_msg = list_entry(intf->waiting_msgs.next,
>> + struct ipmi_smi_msg, link);
>> +list_del(&smi_msg->link);
>> +if (!run_to_completion)
>> +spin_unlock_irqrestore(&intf->waiting_msgs_lock, flags);
> Yikes, what's going on here?  How is the list protected if the spinlock
> isn't taken?
>
> I went to the comment over ipmi_smi.run_to_completion but it doesn't
> explain how it governs the locking strategy at all.  If there's some
> other way in which the reader is supposed to grok IPMI locking, please
> clue me in ;)
>
The "run_to_completion" mode is designed to run at panic time so that 
the watchdog timer can be extended and panic information can be stored 
in the IPMI event log.  In that case locks are irrelevant and can cause 
hangs, so they are skipped.

This is documented a little better in ipmi_si_intf.c, but you are right, 
it's not terribly complete.

-corey

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Multiple users sending messages via KCS interface

[Corey Minyard]

You don't mention the kernel version or anything of that nature.  There 
was a bug fixed a while back for something that looked like this.

-corey

On 04/05/2012 09:15 PM, dbashaw wrote:
> I have two IPMI users created using ipmi_create_user(..).
> Each user can send messages async with respect to each other.
> I have also seen IPMI message handler: BMC returned incorrect response
> errors some times.
>
> When I allow only one user to use the KCS interface this does not seem
> to happen.
> After reviewing ipmi_msghandler.c I am not able to figure out how a
> response to a message
> from a given user can be identified with that user and not some other.
>
>ipmi_msghandler() sends the message to the interface handler (KCS
> state machine in this case) and is done,
> free to handle the next user request since responses arrive
> asynchronously at a later time.
>
>   From the IPMI spec I see KCS message request format described as:
>   BYTE 1BYTE 2 BYTE 3:N
>  NetFn/Lun Cmd Data
>
> KCS message response format:
>   BYTE 1BYTE 2 BYTE 3  BYTE 4:N
>NetFn/Lun   CmdCcode Data
>
> Data is that which is required by the specific command being sent only.
>
> Request and response messages both have no user identifiable information
> that I can find in the V1.5 or V2.0 spec.
>
> I'm beginning to think that this is the reason for the "incorrect
> response" error above when two users are
> sending requests.
>
> handle_new_recv_msg((ipmi_smi_t  intf,
>  struct ipmi_smi_msg *msg)
>   } else if (((msg->rsp[0]>>  2) != ((msg->data[0]>>  2) | 1))
>  || (msg->rsp[1] != msg->data[1])) {
>   /*
>* The NetFN and Command in the response is not even
>* marginally correct.
>*/
>   printk(KERN_WARNING PFX "BMC returned incorrect response,"
>  " expected netfn %x cmd %x, got netfn %x cmd %x\n",
>  (msg->data[0]>>  2) | 1, msg->data[1],
>  msg->rsp[0]>>  2, msg->rsp[1]);
>
> No information in msg->rsp or msg->data can be used to make sure this
> response is associated with
> the correct user. Higher level things like sequence numbers are
> contained in the msg struct at some level
> but don't address the issue of associating the response to a unique user.
>
> How to fix this?
>
> Dave
>
>
>
>
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] IPMI device file locking

[Corey Minyard]

On 06/26/2012 09:33 PM, dbashaw wrote:
> I have a question about using ipmi_watchdog, ipmitool, and another open
> source program ipmisensors together
> at the same time.
>
> ipmitool uses the /dev/ipmi0 char interface. So does (can)
> ipmi_watchdog. ipmisensors uses ipmi_settime(..) to send
> messages via KCS.
>
> Question: is there any type of file locking going on for /dev/ipmi0
> device when two programs attempt to use the
> /dev/ipmi0 interface?

The IPMI driver properly multiplexes all this, so it's not an issue.

-corey

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 1/1 v2 ] ipmi: Setting OS name as Linux in BMC

[Corey Minyard]

Srinivas, what is your use case?

-corey

On 06/28/2012 07:01 PM, Andi Kleen wrote:
>  writes:
>> +
>> +data[0] = param_select;
>> +data[1] = set_selector;
>> +data[2] = string_encode;
>> +data[3] = str_len;
>> +data[4] = 'L';
>> +data[5] = 'i';
>> +data[6] = 'n';
>> +data[7] = 'u';
>> +data[8] = 'x';
> Not sure that's all that useful. I can just see BMC's making the ACPI
> mistake of trying to work around specific issues, by checking for
> Linux.
>
> But since there are so many different Linux that will never work
> because "Linux" does not describe a fixed release or code base.
>
> Probably dangerous.
>
> -Andi
>
>



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 1/1 v2 ] ipmi: Setting OS name as Linux in BMC

[Corey Minyard]

On 06/29/2012 07:30 AM, Matthew Garrett wrote:
> On Thu, Jun 28, 2012 at 05:01:54PM -0700, Andi Kleen wrote:
>> Not sure that's all that useful. I can just see BMC's making the ACPI
>> mistake of trying to work around specific issues, by checking for
>> Linux.

I'm not sure I see that happening, but I suppose you never know.

>>
>> But since there are so many different Linux that will never work
>> because "Linux" does not describe a fixed release or code base.
>>
>> Probably dangerous.
> Agreed. Linux doesn't make interface guarantees to hardware, and where
> we've implied that we do it's ended up breaking things.
>

This is not really about making interface guarantees to hardware. This 
is more of a management discovery thing, so that system management 
software talking to the BMC can know what is running on the target.  
Something where management software can say "Hey, why is Linux running 
on that box? It's supposed to be BSD." or "That box has booted Linux but 
hasn't started its maintenance software". According to the spec, the 
information is supposed to be cleared if the system powers down or resets.

It seems to me that it's better to directly query what is running on the 
target to know what is running on it, but perhaps that's a security 
problem waiting to happen.  And perhaps it's better to have a small 
program set this at startup, since this operation will currently fail on 
the majority of systems out there.

-corey

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 1/1 v2 ] ipmi: Setting OS name as Linux in BMC

[Corey Minyard]

On 07/04/2012 07:17 AM, Andi Kleen wrote:
>> Rather than just have a static entry such as 'Linux' I could probably write 
>> the version number and more(distro name etc.. )
>>
>> Thoughts.. ?
> I still think "Linux" means nothing even to the management software.
> What should it do with that?
>
> If you provide some way for a distro to fill in "foobar linux 1.2.3.4"
> maybe. But just Linux or even Linux x.y.z would be wrong because the same 
> kernel
> version can behave very differently.
>
> But it would be  better to define specific feature flags for
> specific needs that actually mean something.

I think the conclusion I have come to is that this really belongs as a 
small program that runs at startup.  That's not significantly different 
than having it done in the driver.  I can help you write it, if you like.

I think Andi is right here.  "Linux" may mean something to your 
management software.  Some other management software may want "Linux 
x.y.z".  Another may want "SuSE Enterprise Linux x.y".  It's impossible 
to be general enough in the kernel.

>
>> I know there were some concerns with the security aspect, Can you please let 
>> me know what kind of security holes we could be looking at ?
> I don't think there are any security problems. just forward/backward
> compatibility problems, as the ACPI experience shows.

I had mentioned possible security issues with having some daemon that 
identified the system directly over IP.  I don't think there are any 
issues with IPMI, at least not any more than you already have with IPMI, 
and it's reasonably secure for what it does.

-corey

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] PM / IPMI: Remove empty legacy PCI PM callbacks

[Corey Minyard]

Looks fine to me.

Acked-by: Corey Minyard 

On 07/06/2012 03:02 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
>
> The legacy PM callbacks provided by the IPMI PCI driver are
> empty routines returning 0, so they can be safely dropped.
>
> Signed-off-by: Rafael J. Wysocki 
> ---
>   drivers/char/ipmi/ipmi_si_intf.c |   16 
>   1 file changed, 16 deletions(-)
>
> Index: linux/drivers/char/ipmi/ipmi_si_intf.c
> ===
> --- linux.orig/drivers/char/ipmi/ipmi_si_intf.c
> +++ linux/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2503,18 +2503,6 @@ static void __devexit ipmi_pci_remove(st
>   cleanup_one_si(info);
>   }
>   
> -#ifdef CONFIG_PM
> -static int ipmi_pci_suspend(struct pci_dev *pdev, pm_message_t state)
> -{
> - return 0;
> -}
> -
> -static int ipmi_pci_resume(struct pci_dev *pdev)
> -{
> - return 0;
> -}
> -#endif
> -
>   static struct pci_device_id ipmi_pci_devices[] = {
>   { PCI_DEVICE(PCI_HP_VENDOR_ID, PCI_MMC_DEVICE_ID) },
>   { PCI_DEVICE_CLASS(PCI_ERMC_CLASSCODE, PCI_ERMC_CLASSCODE_MASK) },
> @@ -2527,10 +2515,6 @@ static struct pci_driver ipmi_pci_driver
>   .id_table = ipmi_pci_devices,
>   .probe =ipmi_pci_probe,
>   .remove =   __devexit_p(ipmi_pci_remove),
> -#ifdef CONFIG_PM
> - .suspend =  ipmi_pci_suspend,
> - .resume =   ipmi_pci_resume,
> -#endif
>   };
>   #endif /* CONFIG_PCI */
>   



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] Code moved to git, looking at old bug items

[Corey Minyard]

I just got tired of using CVS, so I finally converted the repository 
over to git.  It's a lot nicer to use.  I've imported all the history.  
If I had known it would be that easy, I would have done it earlier.

I've also added a kernel git repository with the kernel patches. This 
should make it easier for me to keep things up to date.

And I had been neglecting the bugs.  I've gone through some of them; 
I'll be spending time on that in the near future.

Thanks,

-corey

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] ipmi_si messages

[Corey Minyard]

On 09/18/2012 12:47 PM, David Bashaw wrote:
>
> I have a 2.6.32 kernel running on two different machines.
>
> The init messages look different and I’m not sure why.
>
> Machine A:
>
> IPMI System Interface driver.
>
> ipmi_si: Adding SMBIOS-specified kcs state machine
>
> ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 
> 0xca8, slave address 0x20, irq 0
>
> ipmi: Found new BMC (man_id: 0x0019fd, prod_id: 0x19e7, dev_id: 0x20)
>
> IPMI kcs interface initialized
>
> IPMI Watchdog: driver initialized
>
> ipmi device interface
>
> Machine B:
>
> IPMI System Interface driver.
>
> ipmi_si: Adding SMBIOS-specified kcs state machine
>
> ipmi_si: Adding ACPI-specified kcs state machine
>
> ipmi_si: Trying SMBIOS-specified kcs state machine at mem address 0x0, 
> slave çaddress 0x0 ?
>
> address 0x20, irq 0
>
> Could not set up I/O space
>
> ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, 
> slave
>
> address 0x0, irq 0
>
> ipmi: Found new BMC (man_id: 0x0019fd, prod_id: 0x1ee6, dev_id: 0x20)
>
> IPMI kcs interface initialized
>
> IPMI Watchdog: driver initialized
>
> So what is the reason SMBIOS failed on machine B? The SMBIOS messages 
> themselves are different between the two machines.
>

It appears that the SMBIOS table is bogus on machine B. Do a "dmidecode" 
on machine B and search for IPMI to see the table entry and be sure.

> Do SMBIOS and ACPI both exist in the BIOS at the same time?
>

Yes, they do. The IPMI driver prefers SMBIOS because it carries the 
slave address. That's not available in ACPI.

-corey

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] Location of newer kernel sources

[Corey Minyard]

I while ago I moved to keeping the IPMI driver updates in a git 
repository.  Unfortunately, I didn't tell anyone.


So, access to the IPMI driver for newer versions of the kernel is 
currently available at 
git//openipmi.git.sourceforge.net/gitroot/openipmi/linux-ipmi under 
obvious branch names (like v3.4-ipmi)|.


-corey
|
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 4/5] IPMI: Fix some uninitialized warning

[Corey Minyard]

On 10/22/2012 06:49 PM, Andrew Morton wrote:
> On Tue, 16 Oct 2012 15:53:39 -0500
> miny...@acm.org wrote:
>
>> From: Corey Minyard 
>>
>> There was a spot where the compiler couldn't tell some variables
>> would be set.  So initialize them to make the warning go away.
>>
>> Signed-off-by: Corey Minyard 
>> ---
>>   drivers/char/ipmi/ipmi_msghandler.c |2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
>> b/drivers/char/ipmi/ipmi_msghandler.c
>> index 2c29942..a0c84bb 100644
>> --- a/drivers/char/ipmi/ipmi_msghandler.c
>> +++ b/drivers/char/ipmi/ipmi_msghandler.c
>> @@ -1880,7 +1880,7 @@ int ipmi_request_supply_msgs(ipmi_user_t  user,
>>   struct ipmi_recv_msg *supplied_recv,
>>   int  priority)
>>   {
>> -unsigned char saddr, lun;
>> +unsigned char saddr = 0, lun = 0;
>>  int   rv;
>>   
>>  if (!user)
> The kernel build actually generates quite a lot of "bar uninitialised"
> warnings for foo(&bar) expressions.  I just ignore them, because later
> versions of gcc stopped doing that.
>
> The fix is OK, I suppose.  But it will cause additional code to be
> emitted.  Using uninitialized_var() avoids that, and makes things
> clearer to the reader.
Well, warnings annoy me, especially when I get the emails about them.  
But I suppose that's the point of the emails :).

I'll do a patch to switch it to uninitialized_var() for the next set of 
things I send.  Thanks.

-corey


--
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] python binding and PYPI

[Corey Minyard]

On 12/02/2012 08:59 PM, Lu, Lianhao wrote:
> Hi guys,
>
> Is there any plan to put openipmi python binding to 
> http://pypi.python.org/pypi, so the users can easily install the OpenIPMI 
> python module through pip? Some distributions(i.e. Ubuntu, etc.) don't 
> provide its native package for the openIPMI python binding.
>
> Best Regards,
> -Lianhao
>
No plans at the moment, I'm not really sure what this is.  But if some 
one (hint, hint) wants to do the work, that would be fine with me.  I'll 
happily work with someone to get any required changes in.

-corey

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: add new kernel options to prevent automatic ipmi init

[Corey Minyard]

Well, the built-in driver works on systems that have more than one interface
and more than one BMC, and multiple IPMBs (and all of the other channel
types for that matter, and the driver handles all the multiplexing and nasty
addressing).  There is, in fact, no arbitrary limit, and IBM tested
this fairly extensively with some of their systems.  I'm not sure why you
would need a custom driver, and if there are some custom things that need
to be done for your servers, I'd be happy to add that.  I've worked with a
number of other vendors to get changes like this in.  And then ipmitool,
freeipmi, openipmi, etc. will work with the device.

I don't have a big problem with this patch.  I wonder why you would want
to compile the standard driver into your kernel if you expected to load a
module with a custom driver later, though.  None of the distros I know of
compile it in, it's always a module.

You can also dynamically remove the device from the driver using the hot
add/remove capability.  To remove it, you can do:
   echo remove,`cat /proc/ipmi/0/params`
and it will disassociate that device (IPMI interface 0 in this case) 
from the
driver.  So you can iterate through all the devices in /proc/ipmi and
remove them all at startup.

If none of the above options work for you, we can go ahead with this
patch.  Just wanted to let you know that current options exist, and see
if you wanted to take a different direction.

-corey

On 12/13/2012 12:40 PM, Tony Camuso wrote:
> The configuration change building ipmi_si into the kernel precludes the
> use of a custom driver that can utilize more than one KCS interface,
> multiple IPMBs, and more than one BMC. This capability is important for
> fault-tolerant systems.
>
> Even if the kernel option ipmi_si.trydefaults=0 is specified, ipmi_si
> discovers and claims one of the KCS interfaces on a Stratus server.
> The inability to now prevent the kernel from managing this device is a
> regression from previous kernels. The regression breaks a capability
> fault-tolerant vendors have relied upon.
>
> To support both ACPI opregion access and the need to avoid activation
> of ipmi_si on some platforms, we've added two new kernel options,
> ipmi_si.tryacpi and ipmi_si.trydmi be added to prevent ipmi_si from
> initializing when these options are set to 0 on the kernel command line.
> With these options at the default value of 1, ipmi_si init proceeds
> according to the kernel default.
>
> Tested-by: Jim Paradis 
> Signed-off-by: Robert Evans 
> Signed-off-by: Jim Paradis 
> Signed-off-by: Tony Camuso 
> ---
>   drivers/char/ipmi/ipmi_si_intf.c | 28 
>   1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 20ab5b3..0a441cf 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1208,6 +1208,12 @@ static int smi_num; /* Used to sequence the SMIs */
>   #define DEFAULT_REGSPACING  1
>   #define DEFAULT_REGSIZE 1
>   
> +#ifdef CONFIG_ACPI
> +static int   si_tryacpi = 1;
> +#endif
> +#ifdef CONFIG_DMI
> +static int   si_trydmi = 1;
> +#endif
>   static bool  si_trydefaults = 1;
>   static char  *si_type[SI_MAX_PARMS];
>   #define MAX_SI_TYPE_STR 30
> @@ -1238,6 +1244,16 @@ MODULE_PARM_DESC(hotmod, "Add and remove interfaces.  
> See"
>" Documentation/IPMI.txt in the kernel sources for the"
>" gory details.");
>   
> +#ifdef CONFIG_ACPI
> +module_param_named(tryacpi, si_tryacpi, bool, 0);
> +MODULE_PARM_DESC(tryacpi, "Setting this to zero will disable the"
> +  " default scan of the interfaces identified via ACPI");
> +#endif
> +#ifdef CONFIG_DMI
> +module_param_named(trydmi, si_trydmi, bool, 0);
> +MODULE_PARM_DESC(trydmi, "Setting this to zero will disable the"
> +  " default scan of the interfaces identified via DMI");
> +#endif
>   module_param_named(trydefaults, si_trydefaults, bool, 0);
>   MODULE_PARM_DESC(trydefaults, "Setting this to 'false' will disable the"
>" default scan of the KCS and SMIC interface at the standard"
> @@ -3408,16 +3424,20 @@ static int init_ipmi_si(void)
>   #endif
>   
>   #ifdef CONFIG_ACPI
> - pnp_register_driver(&ipmi_pnp_driver);
> - pnp_registered = 1;
> + if (si_tryacpi) {
> + pnp_register_driver(&ipmi_pnp_driver);
> + pnp_registered = 1;
> + }
>   #endif
>   
>   #ifdef CONFIG_DMI
> - dmi_find_bmc();
> + if (si_trydmi)
> + dmi_find_bmc();
>   #endif
>   
>   #ifdef CONFIG_ACPI
> - spmi_find_bmc();
> + if (si_tryacpi)
> + spmi_find_bmc();
>   #endif
>   
>   /* We prefer devices with interrupts, but in the case of a machine


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile

Re: [Openipmi-developer] [PATCH] ipmi: add new kernel options to prevent automatic ipmi init

[Corey Minyard]

On 12/14/2012 10:25 AM, Evans, Robert wrote:
> Corey,
>
> Thanks for the thoughtful reply.  Below I respond in detail to
> these three points.
>
> 1) Why building a variant kernel with ipmi_si as a module is not
> feasible.
>
> 2) User mode access to IPMI on Stratus systems (e.g. ipmitool).
>
> 3) ipmi_si hot removal seems to not work as needed.
>
> Stratus might be able to use the hot removal option instead of the
> proposed patch if hot removal can remove all interfaces from usage
> by ipmi_si.  Our testing of this option was not successful as
> shown below.
>
>   - - -
>
> 1) Why building a variant kernel with ipmi_si as a module is not
> feasible:
>
> Stratus sells servers based upon Red Hat Enterprise Linux (RHEL).
> In the next release of RHEL, ipmi_si will be built into the kernel
> so that access to ACPI opregion is available early in kernel
> startup.  Stratus systems run the Red Hat kernel so that the
> system is certified and supported by Red Hat.  For this reason
> using a custom kernel configured to build ipmi_si as a module is
> not an option.

Yes, the RHEL engineer explained this to me, and it makes sense now. Thanks.

>
>
> 2) User mode access to IPMI on Stratus systems:
>
> Although Stratus provides a replacement for ipmi_si, we depend
> on ipmi_msghandler and ipmi_devintf.  The device /dev/ipmi0 is
> present and this device is utilized by the user-mode system
> management software Stratus supplies.
>
> Therefore other programs like ipmitool can send IPMI commands and
> get responses on Stratus systems.

Ah, ok. That's good.

>
>
>
> 3) Hot removal of the KCS interfaces discovered by ipmi_si seems
> to not do enough... One KCS cannot successfully be removed:
>
> Based upon your suggestion, we tried to use hot removal.  With
> RHEL 6.4 Beta (kernel-2.6.32-343.el6), Stratus attempted to hot
> remove the IPMI interfaces.  This was booted with
>   "ipmi_si.trydefaults=0"
> although we expect that kernel option to have no effect since a
> BMC is found before the defaults would be tried.
>
> This is logged when ipmi_si initializes indicating that both BMCs
> were discovered:
>
> ipmi message handler version 39.2
> IPMI System Interface driver.
> ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2,
> slave address 0x0, irq 0
> ipmi: Found new BMC (man_id: 0x77,  prod_id: 0x05c6, dev_id: 0x41)
> IPMI kcs interface initialized
> ipmi_si: Adding SMBIOS-specified kcs state machine
> ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xda2,
> slave address 0x20, irq 0
> ipmi: interfacing existing BMC (man_id: 0x77, prod_id: 0x05c6,
> dev_id: 0x41)
> IPMI kcs interface initialized
>
> Although there are two different BMCs, because it says
>   "interfacing existing BMC"
> it appears that ipmi_si assumes they are the same BMC.

That's happening in the message handler and it happens because the
manufacturer, product, and device id all match. From the spec:

The Device ID is typically used in combination with the Product ID
field such
that the Device IDs for different controllers are unique under a
given Product
ID. A controller can optionally use the Device ID as an ‘instance’
identifier if
more than one controller of that kind is used in the system.
(Section 20.1)

Different controllers in the same system are supposed to have different 
device
IDs.

>
> Also, I notice the slave address for the first KCS (port CA2) seems
> wrong.  Maybe these findings are relevant to what happens next.

Probably not relevant. It's not correct because, for some bizarre
reason, the slave address is not present in the ACPI information.
The slave address is only used by the message handler for the
IPMB return address on messages routed over IPMB.

It is odd that one interface is specified in ACPI and the other in DMI.
You can specify all of them in both tables.

>
> After ipmi_si has been initialized, a script runs to load ftmod, the
> module that contains the Stratus IPMI driver.  This code was added to
> hot remove the interfaces discovered by ipmi_si before loading ftmod:
>
> for i in $(cd /proc/ipmi; ls)
> do
>  dev="IPMI${i}"
>  params="$(cat /proc/ipmi/${i}/params)"
>  msg="Considering removal of dev: ${dev} ${params}"
>  logger -p kern.info -t `basename ${0}` "${msg}"
>  echo "${msg}" > /dev/console
>  [ -n "${params}" ] &&
>   echo "remove,`cat /proc/ipmi/${i}/params`" \
>   > /sys/module/ipmi_si/parameters/hotmod
> done
>
> In the console log we can see this script run prior to loading the
> Stratus ftmod.ko and we also see that ftmod exposes a BMC:
>
> Considering removal of dev: IPMI0
> kcs,i/o,0xca2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=0
> Considering removal of dev: IPMI1
> kcs,i/o,0xda2,rsp=1,rsi=1,rsh=0,irq=0,ipmb=32
> ftmod: module license 'LGPL' taints kernel.
> Disabling lock debugging due to kernel taint
> FTMOD version lsb-ft-ftmod-9.0.4-209
> ftmod: GLOBAL_SIZE=4194304
> ftmod: global_cc_memory 0x

Re: [Openipmi-developer] FW: BMC returned incorrect response, expected

[Corey Minyard]

Sorry, I missed this.  What version of Linux?  I believe this has been 
fixed a while ago, but you may not have the fix.

-corey

On 03/01/2013 05:08 PM, David Bashaw wrote:
> I sent this some time ago. Is anyone still actively working IPMI bugs?
> I would like to make some progress on this issue. We see this on lots of 
> machines here.
>
> Regards.
>
> Dave
>
>
> -Original Message-
> From: David Bashaw
> Sent: Tuesday, January 22, 2013 3:04 PM
> To: Openipmi-developer@lists.sourceforge.net
> Subject: BMC returned incorrect response, expected
>
> Hello. Still chasing this bug.
>
> I posted some time ago some debugs and was asked to clean them up and try 
> again.
>
> So, I re-coded my debug.
> The messages are below and the code change follows.
>
> ==
>   ( 1  )  handle_transaction_done: smi cmd:0x2c does not match the smi 
> cmd:0x06 in response  ( 2 )  handle_transaction_done: smi netfn:0x07 does not 
> match user data cmd:0x2d IPMI message handler: BMC returned incorrect 
> response, expected netfn 2d cmd 0, got netfn 7 cmd 35 msgid:0
> handle_transaction_done: smi cmd:0x06 does not match the smi cmd:0x2c in 
> response
> handle_transaction_done: smi netfn:0x2d does not match user data cmd:0x07 
> IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 
> 1, got netfn 2d cmd 0 msgid:1 ==
>
> It appears the command and response in SMI message do not match what is in 
> the user data.
> I hope this is helpful.
>
> Dave
>
> static void handle_transaction_done(struct smi_info *smi_info) {
>  struct ipmi_smi_msg *msg;
>  struct ipmi_recv_msg *recv_msg;
>  unsigned long user;
>
> #ifdef DEBUG_TIMING
>  struct timeval t;
> #endif
>
>  switch (smi_info->si_state) {
>  case SI_NORMAL:
>  if (!smi_info->curr_msg)
>  break;
>
>  smi_info->curr_msg->rsp_size
>  = smi_info->handlers->get_result(
>  smi_info->si_sm,
>  smi_info->curr_msg->rsp,
>  IPMI_MAX_MSG_LENGTH, &user);
>
>  recv_msg = (struct ipmi_recv_msg *) 
> smi_info->curr_msg->user_data;
>  if (recv_msg) {
>  int err = 0;
>  u8 msgCmd = (smi_info->curr_msg->data[0] >> 2);  /* 
> the request */
>  u8 CurMsgCmd = ((smi_info->curr_msg->rsp[0] >> 2) & 
> 0xFE);  /* the resp */
>  u8 smiCmd = smi_info->curr_msg->data[1];
>  u8 RecvMsgCmd = recv_msg->msg.cmd;
>  u8 smiNetfn = (smi_info->curr_msg->rsp[0] >> 2);
>  u8 RecvMsgNetfn = (recv_msg->msg.netfn | 1);
>
> ( 1 )   ---  /* check req and rsp match between smi 
> msg->data[] and smi msg->rsp[] */
>  if (msgCmd != CurMsgCmd) {
>  printk(KERN_ERR "%s: smi cmd:0x%02x does not 
> match the smi cmd:0x%02x in response\n",
>  __FUNCTION__, msgCmd, CurMsgCmd);
>  ++err;
>  }
>
>   ( 2  )    /* compare smi cmd and userdata cmd */
>  if (smiCmd != RecvMsgCmd) {
>  printk(KERN_ERR "%s: smi cmd:0x%02x does not 
> match user data cmd:0x%02x\n",
>  __FUNCTION__, smiCmd, RecvMsgCmd);
>  ++err;
>  }
>
>  /* compare smi request netfn matches user data netfn 
> */
>  if (smiNetfn != RecvMsgNetfn) {
>  printk(KERN_ERR "%s: smi netfn:0x%02x does 
> not match user data cmd:0x%02x\n",
>  __FUNCTION__, smiNetfn, 
> RecvMsgNetfn);
>  ++err;
>  }
>  if (err) {
>  smi_inc_stat(smi_info, 
> bmc_incorrect_responses);
>  }
>  }
>
>
> --
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
__

Re: [Openipmi-developer] [PATCH] drivers: char: ipmi: Replaced kmalloc and strcpy with kstrdup

[Corey Minyard]

On 03/16/2013 09:16 AM, Alexandru Gheorghiu wrote:
> Replaced calls to kmalloc followed by strcpy with a sincle call to kstrdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---
>   drivers/char/ipmi/ipmi_msghandler.c |3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
> b/drivers/char/ipmi/ipmi_msghandler.c
> index 053201b..617b443 100644
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@ -2037,12 +2037,11 @@ int ipmi_smi_add_proc_entry(ipmi_smi_t smi, char 
> *name,
>   entry = kmalloc(sizeof(*entry), GFP_KERNEL);
>   if (!entry)
>   return -ENOMEM;
> - entry->name = kmalloc(strlen(name)+1, GFP_KERNEL);
> + entry->name = kstrdup(name, GFP_KERNEL);
>   if (!entry->name) {
>   kfree(entry);
>   return -ENOMEM;
>   }
> - strcpy(entry->name, name);
>   
>   file = proc_create_data(name, 0, smi->proc_dir, proc_ops, data);
>   if (!file) {
Looks good to me.

Acked-by: Corey Minyard 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] drivers: char: ipmi: Replaced kmalloc and strcpy with kstrdup

[Corey Minyard]

On 03/16/2013 09:16 AM, Alexandru Gheorghiu wrote:
> Replaced calls to kmalloc followed by strcpy with a sincle call to kstrdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu 
> ---
>   drivers/char/ipmi/ipmi_msghandler.c |3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
> b/drivers/char/ipmi/ipmi_msghandler.c
> index 053201b..617b443 100644
> --- a/drivers/char/ipmi/ipmi_msghandler.c
> +++ b/drivers/char/ipmi/ipmi_msghandler.c
> @@ -2037,12 +2037,11 @@ int ipmi_smi_add_proc_entry(ipmi_smi_t smi, char 
> *name,
>   entry = kmalloc(sizeof(*entry), GFP_KERNEL);
>   if (!entry)
>   return -ENOMEM;
> - entry->name = kmalloc(strlen(name)+1, GFP_KERNEL);
> + entry->name = kstrdup(name, GFP_KERNEL);
>   if (!entry->name) {
>   kfree(entry);
>   return -ENOMEM;
>   }
> - strcpy(entry->name, name);
>   
>   file = proc_create_data(name, 0, smi->proc_dir, proc_ops, data);
>   if (!file) {
Actually, I should say that I've pulled this into my tree.

Thanks,

-corey

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

[Corey Minyard]

Yes, this is correct, I've pulled it into my tree.

-corey

On 03/29/2013 02:18 AM, Chen Gang wrote:
>when calling memcpy, read_data and write_data need additional 2 bytes.
>
>write_data:
>  for checking:  "if (size > IPMI_MAX_MSG_LENGTH)"
>  for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)"
>
>read_data:
>  for checking:  "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)"
>  for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)"
>
>
> Signed-off-by: Chen Gang 
> ---
>   drivers/char/ipmi/ipmi_bt_sm.c |4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
> index cdd4c09f..a22a7a5 100644
> --- a/drivers/char/ipmi/ipmi_bt_sm.c
> +++ b/drivers/char/ipmi/ipmi_bt_sm.c
> @@ -95,9 +95,9 @@ struct si_sm_data {
>   enum bt_states  state;
>   unsigned char   seq;/* BT sequence number */
>   struct si_sm_io *io;
> - unsigned char   write_data[IPMI_MAX_MSG_LENGTH];
> + unsigned char   write_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
>   int write_count;
> - unsigned char   read_data[IPMI_MAX_MSG_LENGTH];
> + unsigned char   read_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
>   int read_count;
>   int truncated;
>   longtimeout;/* microseconds countdown */


--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] "Could not enable interrupts" despite interrupts working

[Corey Minyard]

On 05/09/2013 04:00 PM, Andy Lutomirski wrote:
> IPMI in polled mode sucks enough that this warning is alarming:
>
> ipmi_si ipmi_si.0: Could not enable interrupts, failed set, using polled mode.
>
> On two of my Dell gen 7 (I think) servers, this warning prints, but
> IPMI uses interrupts.  Can the warning be fixed?
>
> (I have a server that says this, and IPMI, if loaded, sucks CPU.  That
> server should keep the warning.)

That warning means that it tried to send the command to enable 
interrupts, and the command failed.  The controller is supposed to 
accept that command if it has interrupts, so there's not really a way, 
outside of some sort of blacklist, for the code to know that a system 
has interrupts even if the command fails.

-corey

>
> --Andy
>


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] "Could not enable interrupts" despite interrupts working

[Corey Minyard]

On 05/10/2013 01:31 PM, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 5:16 AM, Corey Minyard  wrote:
>> On 05/09/2013 04:00 PM, Andy Lutomirski wrote:
>>> IPMI in polled mode sucks enough that this warning is alarming:
>>>
>>> ipmi_si ipmi_si.0: Could not enable interrupts, failed set, using polled
>>> mode.
>>>
>>> On two of my Dell gen 7 (I think) servers, this warning prints, but
>>> IPMI uses interrupts.  Can the warning be fixed?
>>>
>>> (I have a server that says this, and IPMI, if loaded, sucks CPU.  That
>>> server should keep the warning.)
>>
>> That warning means that it tried to send the command to enable interrupts,
>> and the command failed.  The controller is supposed to accept that command
>> if it has interrupts, so there's not really a way, outside of some sort of
>> blacklist, for the code to know that a system has interrupts even if the
>> command fails.
>>
> Somehow the driver manages not to poll on this system.  How does that work?

In that particular instance, interrupts are still enabled and configured 
and will come in and be handled.  It does not enable polling mode in 
that instance, and will run slowly if interrupts don't really work.  
That's the decision I made in that case.  If the hardware advertises 
interrupts but does not support enable, I'd guess it still has interrupts.

-corey

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] "Could not enable interrupts" despite interrupts working

[Corey Minyard]

On 05/10/2013 01:47 PM, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 11:45 AM, Corey Minyard  wrote:
>> On 05/10/2013 01:31 PM, Andy Lutomirski wrote:
>>> On Fri, May 10, 2013 at 5:16 AM, Corey Minyard 
>>> wrote:
>>>> On 05/09/2013 04:00 PM, Andy Lutomirski wrote:
>>>>> IPMI in polled mode sucks enough that this warning is alarming:
>>>>>
>>>>> ipmi_si ipmi_si.0: Could not enable interrupts, failed set, using polled
>>>>> mode.
>>>>>
>>>>> On two of my Dell gen 7 (I think) servers, this warning prints, but
>>>>> IPMI uses interrupts.  Can the warning be fixed?
>>>>>
>>>>> (I have a server that says this, and IPMI, if loaded, sucks CPU.  That
>>>>> server should keep the warning.)
>>>>
>>>> That warning means that it tried to send the command to enable
>>>> interrupts,
>>>> and the command failed.  The controller is supposed to accept that
>>>> command
>>>> if it has interrupts, so there's not really a way, outside of some sort
>>>> of
>>>> blacklist, for the code to know that a system has interrupts even if the
>>>> command fails.
>>>>
>>> Somehow the driver manages not to poll on this system.  How does that
>>> work?
>>
>> In that particular instance, interrupts are still enabled and configured and
>> will come in and be handled.  It does not enable polling mode in that
>> instance, and will run slowly if interrupts don't really work.  That's the
>> decision I made in that case.  If the hardware advertises interrupts but
>> does not support enable, I'd guess it still has interrupts.
> In that case, can the driver also print a more informative warning
> like "Failed to enable interrupts; depending on how your hardware is
> buggy, either everything is okay or ipmi will be very slow."?

That's probably a good idea, I'll add that.

Thanks,

-corey

> --Andy


--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: ipmi_devintf: compat_ioctl method failes to take ipmi_mutex

[Corey Minyard]

Yes, you are right.  I've pulled this in to my tree.  Looking at this, 
ipmi_mutex really should go away and be replaced bu something that 
scales better, but I guess it's not that critical for IPMI.

-corey

On 05/13/2013 02:39 PM, Benjamin LaHaise wrote:
> When a 32 bit version of ipmitool is used on a 64 bit kernel, the
> ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
> incomplete data being retrieved in some cases, or other possible failures.
> Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.
> This is probably a candidate for -stable as well.
>
> Signed-off-by: Benjamin LaHaise 
> ---
>   drivers/char/ipmi/ipmi_devintf.c |   14 +-
>   1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
> b/drivers/char/ipmi/ipmi_devintf.c
> index 9eb360f..d5a5f02 100644
> --- a/drivers/char/ipmi/ipmi_devintf.c
> +++ b/drivers/char/ipmi/ipmi_devintf.c
> @@ -837,13 +837,25 @@ static long compat_ipmi_ioctl(struct file *filep, 
> unsigned int cmd,
>   return ipmi_ioctl(filep, cmd, arg);
>   }
>   }
> +
> +static long unlocked_compat_ipmi_ioctl(struct file *filep, unsigned int cmd,
> +unsigned long arg)
> +{
> + int ret;
> +
> + mutex_lock(&ipmi_mutex);
> + ret = compat_ipmi_ioctl(filep, cmd, arg);
> + mutex_unlock(&ipmi_mutex);
> +
> + return ret;
> +}
>   #endif
>   
>   static const struct file_operations ipmi_fops = {
>   .owner  = THIS_MODULE,
>   .unlocked_ioctl = ipmi_unlocked_ioctl,
>   #ifdef CONFIG_COMPAT
> - .compat_ioctl   = compat_ipmi_ioctl,
> + .compat_ioctl   = unlocked_compat_ipmi_ioctl,
>   #endif
>   .open   = ipmi_open,
>   .release= ipmi_release,


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 3/4] ipmi: Improve error messages on failed irq enable

[Corey Minyard]

When the interrupt enable message returns an error, the messages are
not entirely accurate nor helpful.  So improve them.

Signed-off-by: Corey Minyard 
Cc: Andy Lutomirski 
---
 drivers/char/ipmi/ipmi_si_intf.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 313538a..af4b23f 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -663,8 +663,10 @@ static void handle_transaction_done(struct smi_info 
*smi_info)
/* We got the flags from the SMI, now handle them. */
smi_info->handlers->get_result(smi_info->si_sm, msg, 4);
if (msg[2] != 0) {
-   dev_warn(smi_info->dev, "Could not enable interrupts"
-", failed get, using polled mode.\n");
+   dev_warn(smi_info->dev,
+"Couldn't get irq info: %x.\n", msg[2]);
+   dev_warn(smi_info->dev,
+"Maybe ok, but ipmi might run very slowly.\n");
smi_info->si_state = SI_NORMAL;
} else {
msg[0] = (IPMI_NETFN_APP_REQUEST << 2);
@@ -685,10 +687,12 @@ static void handle_transaction_done(struct smi_info 
*smi_info)
 
/* We got the flags from the SMI, now handle them. */
smi_info->handlers->get_result(smi_info->si_sm, msg, 4);
-   if (msg[2] != 0)
-   dev_warn(smi_info->dev, "Could not enable interrupts"
-", failed set, using polled mode.\n");
-   else
+   if (msg[2] != 0) {
+   dev_warn(smi_info->dev,
+"Couldn't set irq info: %x.\n", msg[2]);
+   dev_warn(smi_info->dev,
+"Maybe ok, but ipmi might run very slowly.\n");
+   } else
smi_info->interrupt_disabled = 0;
smi_info->si_state = SI_NORMAL;
break;
-- 
1.7.9.5


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 2/4] drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

[Corey Minyard]

From: Chen Gang 

  when calling memcpy, read_data and write_data need additional 2 bytes.

  write_data:
for checking:  "if (size > IPMI_MAX_MSG_LENGTH)"
for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)"

  read_data:
for checking:  "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)"
for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)"

Signed-off-by: Chen Gang 
Signed-off-by: Corey Minyard 
Cc: sta...@vger.kernel.org
---
 drivers/char/ipmi/ipmi_bt_sm.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
index cdd4c09f..a22a7a5 100644
--- a/drivers/char/ipmi/ipmi_bt_sm.c
+++ b/drivers/char/ipmi/ipmi_bt_sm.c
@@ -95,9 +95,9 @@ struct si_sm_data {
enum bt_states  state;
unsigned char   seq;/* BT sequence number */
struct si_sm_io *io;
-   unsigned char   write_data[IPMI_MAX_MSG_LENGTH];
+   unsigned char   write_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
int write_count;
-   unsigned char   read_data[IPMI_MAX_MSG_LENGTH];
+   unsigned char   read_data[IPMI_MAX_MSG_LENGTH + 2]; /* +2 for memcpy */
int read_count;
int truncated;
longtimeout;/* microseconds countdown */
-- 
1.7.9.5


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 1/4] drivers: char: ipmi: Replaced kmalloc and strcpy with kstrdup

[Corey Minyard]

From: Alexandru Gheorghiu 

Replaced calls to kmalloc followed by strcpy with a sincle call to kstrdup.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
Signed-off-by: Corey Minyard 
---
 drivers/char/ipmi/ipmi_msghandler.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 4d439d2..4445fa1 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2037,12 +2037,11 @@ int ipmi_smi_add_proc_entry(ipmi_smi_t smi, char *name,
entry = kmalloc(sizeof(*entry), GFP_KERNEL);
if (!entry)
return -ENOMEM;
-   entry->name = kmalloc(strlen(name)+1, GFP_KERNEL);
+   entry->name = kstrdup(name, GFP_KERNEL);
if (!entry->name) {
kfree(entry);
return -ENOMEM;
}
-   strcpy(entry->name, name);
 
file = proc_create_data(name, 0, smi->proc_dir, proc_ops, data);
if (!file) {
-- 
1.7.9.5


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 4/4] ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex

[Corey Minyard]

From: Benjamin LaHaise 

When a 32 bit version of ipmitool is used on a 64 bit kernel, the
ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
incomplete data being retrieved in some cases, or other possible failures.
Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.

Signed-off-by: Benjamin LaHaise 
Signed-off-by: Corey Minyard 
Cc: sta...@vger.kernel.org
---
 drivers/char/ipmi/ipmi_devintf.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_devintf.c b/drivers/char/ipmi/ipmi_devintf.c
index 9eb360f..d5a5f02 100644
--- a/drivers/char/ipmi/ipmi_devintf.c
+++ b/drivers/char/ipmi/ipmi_devintf.c
@@ -837,13 +837,25 @@ static long compat_ipmi_ioctl(struct file *filep, 
unsigned int cmd,
return ipmi_ioctl(filep, cmd, arg);
}
 }
+
+static long unlocked_compat_ipmi_ioctl(struct file *filep, unsigned int cmd,
+  unsigned long arg)
+{
+   int ret;
+
+   mutex_lock(&ipmi_mutex);
+   ret = compat_ipmi_ioctl(filep, cmd, arg);
+   mutex_unlock(&ipmi_mutex);
+
+   return ret;
+}
 #endif
 
 static const struct file_operations ipmi_fops = {
.owner  = THIS_MODULE,
.unlocked_ioctl = ipmi_unlocked_ioctl,
 #ifdef CONFIG_COMPAT
-   .compat_ioctl   = compat_ipmi_ioctl,
+   .compat_ioctl   = unlocked_compat_ipmi_ioctl,
 #endif
.open   = ipmi_open,
.release= ipmi_release,
-- 
1.7.9.5


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] [PATCH 0/4] ipmi: Some minor fixes

[Corey Minyard]

Some minor fixes I had queued up.  The last one came in recently (patch 4) 
and it and patch 2 are candidates for stable-kernel.


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 3/4] ipmi: Improve error messages on failed irq enable

[Corey Minyard]

On 05/16/2013 05:23 PM, Andy Lutomirski wrote:
>
>  /* We got the flags from the SMI, now handle them. */
>  smi_info->handlers->get_result(smi_info->si_sm, msg, 4);
> -   if (msg[2] != 0)
> -   dev_warn(smi_info->dev, "Could not enable interrupts"
> -", failed set, using polled mode.\n");
> -   else
> +   if (msg[2] != 0) {
> +   dev_warn(smi_info->dev,
> +"Couldn't set irq info: %x.\n", msg[2]);
> +   dev_warn(smi_info->dev,
> +"Maybe ok, but ipmi might run very 
> slowly.\n");
> +   } else
> Minor nit: it would be nice if these warnings were collapsed into a
> single printk -- that would save me a whitelist entry of acceptable
> KERN_WARNING messages :)

Yeah, the trouble is that checkpatch will give a warning if you split a 
string
between two lines or if a line is longer than 80 characters.  I'm not 
creative
enough to fit it into a single line.  Maybe I'm trying to be too literal 
here,
but I split it into two prints to avoid the warning.

>
> My Dell 12g server says:
>
> [97627.407724] ipmi_si ipmi_si.0: Using irq 10
> [97627.421369] ipmi_si ipmi_si.0: Couldn't set irq info: cc.
> [97627.427389] ipmi_si ipmi_si.0: Maybe ok, but ipmi might run very slowly.
>
> Tested-by: Andy Lutomirski 

Thanks a bunch.

-corey

> --Andy


--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [patch v2] ipmi: info leak in compat_ipmi_ioctl()

[Corey Minyard]

On 05/31/2013 07:46 AM, Dan Carpenter wrote:
> On x86_64 there is a 4 byte hole between ->recv_type and ->addr.

Got it, in my tree now.  Thanks.

>
> Signed-off-by: Dan Carpenter 
> ---
> v2: fixed the changelog a little.  Also added LKML because the
> openipmi is a moderated list (and the moderator thought my email was
> spam).

I apologize, the list gets a lot of spam, and I must have made a mistake.

-corey

>
> diff --git a/drivers/char/ipmi/ipmi_devintf.c 
> b/drivers/char/ipmi/ipmi_devintf.c
> index 9eb360f..8e306ac 100644
> --- a/drivers/char/ipmi/ipmi_devintf.c
> +++ b/drivers/char/ipmi/ipmi_devintf.c
> @@ -810,6 +810,7 @@ static long compat_ipmi_ioctl(struct file *filep, 
> unsigned int cmd,
>   struct ipmi_recv   __user *precv64;
>   struct ipmi_recv   recv64;
>   
> + memset(&recv64, 0, sizeof(recv64));
>   if (get_compat_ipmi_recv(&recv64, compat_ptr(arg)))
>   return -EFAULT;
>   


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] help needed

[Corey Minyard]

On 06/03/2013 08:21 AM, Arvind Kumar wrote:
> m trying to ./configure openipmi2.0.20
> but always getting error as "Could not find headers for the popt library"

A better subject would help keep this from getting tagged as spam.

You need to install the popt-dev package on your system.  How to do that 
depends on your OS vendor.

-corey

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] openipmi patch: Fix incoming packet sequence number checking

[Corey Minyard]

Thanks, I've applied it.

I also increased the size of the msg map to 32 bits with the attached patch.

-corey

On 06/13/2013 03:10 AM, Nikita Yushchenko wrote:

Hi.

I was running OpenIPMI against not-properly-behaving BMC, and discovered a
problem in incoming packet sequence number checking.

Attached patch should fix it.

Nikita


diff --git a/lib/ipmi_lan.c b/lib/ipmi_lan.c
index c138b9e..422b96a 100644
--- a/lib/ipmi_lan.c
+++ b/lib/ipmi_lan.c
@@ -260,12 +260,12 @@ typedef struct lan_ip_data_s
 uint32_t   session_id;
 uint32_t   outbound_seq_num;
 uint32_t   inbound_seq_num;
-uint16_t   recv_msg_map;
+uint32_t   recv_msg_map;
 
 /* RMCP+ specific info */
 uint32_t   unauth_out_seq_num;
 uint32_t   unauth_in_seq_num;
-uint16_t   unauth_recv_msg_map;
+uint32_t   unauth_recv_msg_map;
 unsigned char  working_integ;
 unsigned char  working_conf;
 uint32_t   mgsys_session_id;
@@ -2850,7 +2850,7 @@ check_command_queue(ipmi_con_t *ipmi, lan_data_t *lan)
ranges, so adjust for this. */
 static int
 check_session_seq_num(lan_data_t *lan, uint32_t seq,
-		  uint32_t *in_seq, uint16_t *map,
+		  uint32_t *in_seq, uint32_t *map,
 		  int gt_allowed, int lt_allowed)
 {
 /* Check the sequence number. */
@@ -2862,7 +2862,7 @@ check_session_seq_num(lan_data_t *lan, uint32_t seq,
 	*in_seq = seq;
 } else if ((int) (*in_seq - seq) >= 0 && (int) (*in_seq - seq) <= lt_allowed) {
 	/* It's before the current sequence number, but within lt_allowed. */
-	uint16_t bit = 1 << (*in_seq - seq);
+	uint32_t bit = 1 << (*in_seq - seq);
 	if (*map & bit) {
 	/* We've already received the message, so discard it. */
 	add_stat(lan->ipmi, STAT_DUPLICATES, 1);
@@ -2888,14 +2888,14 @@ check_session_seq_num(lan_data_t *lan, uint32_t seq,
 
 static int
 check_15_session_seq_num(lan_data_t *lan, uint32_t seq,
-			 uint32_t *in_seq, uint16_t *map)
+			 uint32_t *in_seq, uint32_t *map)
 {
 return check_session_seq_num(lan, seq, in_seq, map, 8, 8);
 }
 
 static int
 check_20_session_seq_num(lan_data_t *lan, uint32_t seq,
-			 uint32_t *in_seq, uint16_t *map)
+			 uint32_t *in_seq, uint32_t *map)
 {
 return check_session_seq_num(lan, seq, in_seq, map, 15, 16);
 }
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] Add MODULE_ALIAS for autoloading ipmi driver on ACPI systems

[Corey Minyard]

Ok, it's in my queue.  Sorry I missed this earlier.

-corey

On 07/16/2013 10:00 AM, jordan_hargr...@dell.com wrote:
> I'd submitted this about a year ago but it never made it upstream.
>
> The latest versions of the kernel drivers for ipmi can use ACPI to
> determine the type of BMC device used in the system.  The following
> patch adds a module alias so that udev will autoload the ipmi_si
> driver.
>
> Signed-off-by: Jordan Hargrave 
> ---
>   drivers/char/ipmi/ipmi_si_intf.c |2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 83f85cf..afe3b95 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2246,6 +2246,8 @@ static struct pnp_driver ipmi_pnp_driver = {
>   .remove = __devexit_p(ipmi_pnp_remove),
>   .id_table   = pnp_dev_table,
>   };
> +
> +MODULE_DEVICE_TABLE(pnp, pnp_dev_table);
>   #endif
>
>   #ifdef CONFIG_DMI
>
> --jordan hargrave
> Dell Enterprise Linux Engineering


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers

[Corey Minyard]

On 07/25/2013 07:06 AM, Rafael J. Wysocki wrote:
> On Thursday, July 25, 2013 03:09:35 AM Zheng, Lv wrote:
>> -stable according to the previous conversation.
>>
>>> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
>>> Sent: Thursday, July 25, 2013 7:38 AM
>>>
>>> On Tuesday, July 23, 2013 04:09:15 PM Lv Zheng wrote:
 This patch fixes races caused by unprotected ACPI IPMI transfers.

 We can see the following crashes may occur:
 1. There is no tx_msg_lock held for iterating tx_msg_list in
 ipmi_flush_tx_msg() while it is parellel unlinked on failure in
 acpi_ipmi_space_handler() under protection of tx_msg_lock.
 2. There is no lock held for freeing tx_msg in acpi_ipmi_space_handler()
 while it is parellel accessed in ipmi_flush_tx_msg() and
 ipmi_msg_handler().

 This patch enhances tx_msg_lock to protect all tx_msg accesses to
 solve this issue.  Then tx_msg_lock is always held around complete()
 and tx_msg accesses.
 Calling smp_wmb() before setting msg_done flag so that messages
 completed due to flushing will not be handled as 'done' messages while
 their contents are not vaild.

 Signed-off-by: Lv Zheng 
 Cc: Zhao Yakui 
 Reviewed-by: Huang Ying 
 ---
   drivers/acpi/acpi_ipmi.c |   10 --
   1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c index
 b37c189..527ee43 100644
 --- a/drivers/acpi/acpi_ipmi.c
 +++ b/drivers/acpi/acpi_ipmi.c
 @@ -230,11 +230,14 @@ static void ipmi_flush_tx_msg(struct
>>> acpi_ipmi_device *ipmi)
struct acpi_ipmi_msg *tx_msg, *temp;
int count = HZ / 10;
struct pnp_dev *pnp_dev = ipmi->pnp_dev;
 +  unsigned long flags;

 +  spin_lock_irqsave(&ipmi->tx_msg_lock, flags);
list_for_each_entry_safe(tx_msg, temp, &ipmi->tx_msg_list, head) {
/* wake up the sleep thread on the Tx msg */
complete(&tx_msg->tx_complete);
}
 +  spin_unlock_irqrestore(&ipmi->tx_msg_lock, flags);

/* wait for about 100ms to flush the tx message list */
while (count--) {
 @@ -268,13 +271,12 @@ static void ipmi_msg_handler(struct
>>> ipmi_recv_msg *msg, void *user_msg_data)
break;
}
}
 -  spin_unlock_irqrestore(&ipmi_device->tx_msg_lock, flags);

if (!msg_found) {
dev_warn(&pnp_dev->dev,
 "Unexpected response (msg id %ld) is returned.\n",
 msg->msgid);
 -  goto out_msg;
 +  goto out_lock;
}

/* copy the response data to Rx_data buffer */ @@ -286,10 +288,14 @@
 static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void
>>> *user_msg_data)
}
tx_msg->rx_len = msg->msg.data_len;
memcpy(tx_msg->data, msg->msg.data, tx_msg->rx_len);
 +  /* tx_msg content must be valid before setting msg_done flag */
 +  smp_wmb();
>>> That's suspicious.
>>>
>>> If you need the write barrier here, you'll most likely need a read barrier
>>> somewhere else.  Where's that?
>> It might depend on whether the content written before the smp_wmb() is used 
>> or not by the other side codes under the condition set after the smp_wmb().
>>
>> So comment could be treated as 2 parts:
>> 1. do we need a paired smp_rmb().
>> 2. do we need a smp_wmb().
>>
>> For 1.
>> If we want a paired smp_rmb(), then it will appear in this function:
>>
>> 186 static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
>> 187 acpi_integer *value, int rem_time)
>> 188 {
>> 189 struct acpi_ipmi_buffer *buffer;
>> 190
>> 191 /*
>> 192  * value is also used as output parameter. It represents the 
>> response
>> 193  * IPMI message returned by IPMI command.
>> 194  */
>> 195 buffer = (struct acpi_ipmi_buffer *)value;
>> 196 if (!rem_time && !msg->msg_done) {
>> 197 buffer->status = ACPI_IPMI_TIMEOUT;
>> 198 return;
>> 199 }
>> 200 /*
>> 201  * If the flag of msg_done is not set or the recv length is 
>> zero, it
>> 202  * means that the IPMI command is not executed correctly.
>> 203  * The status code will be ACPI_IPMI_UNKNOWN.
>> 204  */
>> 205 if (!msg->msg_done || !msg->rx_len) {
>> 206 buffer->status = ACPI_IPMI_UNKNOWN;
>> 207 return;
>> 208 }
>> + smp_rmb();
>> 209 /*
>> 210  * If the IPMI response message is obtained correctly, the 
>> status code
>> 211  * will be ACPI_IPMI_OK
>> 212  */
>> 213 buffer->status = ACPI_IPMI_OK;
>> 214 buffer->length = msg->rx_len;
>> 215 memcpy(buffer->data, msg->rx_data, msg->rx_len);
>> 216 }
>>
>> If we don't then there will only be msg content not cor

Re: [Openipmi-developer] [PATCH 03/13] ACPI/IPMI: Fix race caused by the unprotected ACPI IPMI transfers

[Corey Minyard]

On 07/25/2013 07:16 PM, Zheng, Lv wrote:
>>
>> If I understand this correctly, the problem would be if:
>>
>> rem_time = wait_for_completion_timeout(&tx_msg->tx_complete,
>>   IPMI_TIMEOUT);
>>
>> returns on a timeout, then checks msg_done and races with something setting
>> msg_done.  If that is the case, you would need the smp_rmb() before checking
>> msg_done.
>>
>> However, the timeout above is unnecessary.  You are using
>> ipmi_request_settime(), so you can set the timeout when the IPMI command
>> fails and returns a failure message.  The driver guarantees a return message
>> for each request.  Just remove the timeout from the completion, set the
>> timeout and retries in the ipmi request, and the completion should handle the
>> barrier issues.
> It's just difficult for me to determine retry count and timeout value, maybe 
> retry=0, timeout=IPMI_TIMEOUT is OK.
> The code of the timeout completion is already there, I think the quick fix 
> code should not introduce this logic.
> I'll add a new patch to apply your comment.

Since it is a local BMC, I doubt a retry is required.  That is probably 
fine.  Or you could set retry=1 and timeout=IPMI_TIMEOUT/2 if you wanted 
to be more sure, but I doubt it would make a difference.  The only time 
you really need to worry about retries is if you are resetting the BMC 
or it is being overloaded.

>
>> Plus, from a quick glance at the code, it doesn't look like it will properly 
>> handle a
>> situation where the timeout occurs and is handled then the response comes in
>> later.
> PATCH 07 fixed this issue.
> Here we just need the smp_rmb() or holding tx_msg_lock() around the 
> acpi_format_ipmi_response().

If you apply the fix like I suggest, then the race goes away.  If 
there's no timeout and it just waits for the completion, things get a 
lot simpler.

>
> Thanks for commenting.

No problem, thanks for working on this.

-corey

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH v2] BMC support for PARISC machines

[Corey Minyard]

Ok, I have it in my tree.  Rolf mentioned a few cleanup things, but this 
is consistent with what is already there.  I should clean up all the 
things Rolf talked about in all the cases.

Thanks,

-corey

On 07/30/2013 04:13 PM, Thomas Bogendoerfer wrote:
> The last line of PARISC machines (C8000, RP34x0, etc.) have a BMC for
> controlling temperature, fan speed and other stuff. The BMC is connected
> via a special bus and listed in the firmware device tree. This change
> adds support for these BMCs to the IPMI driver.
>
> Signed-off-by: Thomas Bogendoerfer 
> ---
>
> v2: Fixed SMP problem by using smi_alloc_info() to get spinlock initialized
>  correctly
>
> This is the second try to get this change integrated. If you see
> any problems with this patch, please give me hints how to improve
> this patch.
>
>
>   drivers/char/ipmi/ipmi_si_intf.c |   75 
> ++
>   1 file changed, 75 insertions(+)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index af4b23f..1ea4201 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -71,6 +71,11 @@
>   #include 
>   #include 
>   
> +#ifdef CONFIG_PARISC
> +#include /* for register_parisc_driver() stuff */
> +#include 
> +#endif
> +
>   #define PFX "ipmi_si: "
>   
>   /* Measure times between events in the driver. */
> @@ -298,6 +303,9 @@ static int pci_registered;
>   #ifdef CONFIG_ACPI
>   static int pnp_registered;
>   #endif
> +#ifdef CONFIG_PARISC
> +static int parisc_registered;
> +#endif
>   
>   static unsigned int kipmid_max_busy_us[SI_MAX_PARMS];
>   static int num_max_busy_us;
> @@ -2697,6 +2705,62 @@ static struct platform_driver ipmi_driver = {
>   .remove = ipmi_remove,
>   };
>   
> +#ifdef CONFIG_PARISC
> +static int ipmi_parisc_probe(struct parisc_device *dev)
> +{
> + struct smi_info *info;
> +
> + info = smi_info_alloc();
> +
> + if (!info) {
> + dev_err(&dev->dev,
> + "could not allocate memory for PARISC probe\n");
> + return -ENOMEM;
> + }
> +
> + info->si_type   = SI_KCS;
> + info->addr_source   = SI_DEVICETREE;
> + info->io_setup  = mem_setup;
> + info->io.addr_type  = IPMI_MEM_ADDR_SPACE;
> + info->io.addr_data  = dev->hpa.start;
> + info->io.regsize= 1;
> + info->io.regspacing = 1;
> + info->io.regshift   = 0;
> + info->irq   = 0; /* no interrupt */
> + info->irq_setup = NULL;
> + info->dev   = &dev->dev;
> +
> + dev_dbg(&dev->dev, "addr 0x%lx\n", info->io.addr_data);
> +
> + dev_set_drvdata(&dev->dev, info);
> +
> + if (add_smi(info)) {
> + kfree(info);
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
> +static int ipmi_parisc_remove(struct parisc_device *dev)
> +{
> + cleanup_one_si(dev_get_drvdata(&dev->dev));
> + return 0;
> +}
> +
> +static struct parisc_device_id ipmi_parisc_tbl[] = {
> + { HPHW_MC, HVERSION_REV_ANY_ID, 0x004, 0xC0 },
> + { 0, }
> +};
> +
> +static struct parisc_driver ipmi_parisc_driver = {
> + .name = "ipmi",
> + .id_table = ipmi_parisc_tbl,
> + .probe =ipmi_parisc_probe,
> + .remove =   ipmi_parisc_remove,
> +};
> +#endif /* CONFIG_PARISC */
> +
>   static int wait_for_msg_done(struct smi_info *smi_info)
>   {
>   enum si_sm_result smi_result;
> @@ -3462,6 +3526,13 @@ static int init_ipmi_si(void)
>   spmi_find_bmc();
>   #endif
>   
> +#ifdef CONFIG_PARISC
> + register_parisc_driver(&ipmi_parisc_driver);
> + parisc_registered = 1;
> + /* poking PC IO addresses will crash machine, don't do it */
> + si_trydefaults = 0;
> +#endif
> +
>   /* We prefer devices with interrupts, but in the case of a machine
>  with multiple BMCs we assume that there will be several instances
>  of a given type so if we succeed in registering a type then also
> @@ -3608,6 +3679,10 @@ static void cleanup_ipmi_si(void)
>   if (pnp_registered)
>   pnp_unregister_driver(&ipmi_pnp_driver);
>   #endif
> +#ifdef CONFIG_PARISC
> + if (parisc_registered)
> + unregister_parisc_driver(&ipmi_parisc_driver);
> +#endif
>   
>   platform_driver_unregister(&ipmi_driver);
>   


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openip

Re: [Openipmi-developer] HPM upgrade on top of openipmi library?

[Corey Minyard]

On 08/25/2013 11:47 PM, Nikita Yushchenko wrote:
> Hi
>
> Has anyone ever tried to implement firmware upgrade per HPM.1 specification
> on top of openipmi library?
>
> WBR,
> Nikita Yushchenko
>
Firmware upgrades are all custom commands, and nobody has submitted 
anything on that.  I do not have access to the HPM.1 specification nor 
to any hardware, so I can't exactly do it.

-corey

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] openipmi patch: ipmi_lan: auth_cap_done(): do not hide error completion code under EINVAL

[Corey Minyard]

This is good.  I have applied and pushed, thank you.

-corey

On 08/27/2013 05:59 AM, Nikita Yushchenko wrote:
> Hi
>
> Here is a patch against openipmi master branch, that fixes error handling
> in auth_cap_done() routine, making it in line with other similar routines.
>
> Without this patch, in case of connection timeout, application gets call to
> connection callback with err set to EINVAL, that is not describtive and
> can't be properly handled.
>
> Nikita Yushchenko
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] openipmi patch: posix_thread_os_hnd: do not leave timer's running flag after stop

[Corey Minyard]

Ok, patch is applied.

Also, I see that this is going to be racy and needs a lock.  I'll work 
on that.

-corey

On 08/28/2013 02:17 AM, Nikita Yushchenko wrote:
> Hi
>
> Just found a bug in stop_timer() in unix/posix_thread_os_hnd.c
>
> Looks like the same was once fixed in unix/posix_os_hnd.c, but fix was not
> propagated into threaded version.
>
> Patch is attached.
>
> Nikita Yushchenko
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 12.04

[Corey Minyard]

I just uploaded an rc2 version, can you try that?

Thanks,

-corey

On 08/30/2013 12:46 AM, Rishi Kaundinya Mutnuru wrote:
> Hi,
> I have downladed OpenIPMI-2.0.20-rc1 and tried using for developing a 
> hardware monitoring tool.
> I am facing
> compilation issues on ubuntu 12.04 host. I am snipping the error below 
> with the system details.
> Highly appreciate your quick response as this critical for our work.
> 
> $uname -a
> Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 
> x86_64 x86_64 x86_64 GNU/Linux
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 12.04.3 LTS
> Release: 12.04
> Codename: precise
> _jab@__x__:~/OpenIPMI/OpenIPMI-2.0.20-rc1$_ 
> gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc-4.6.real
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 
> 4.6.3-1ubuntu5' 
> --with-bugurl=_file:///usr/share/doc/gcc-4.6/README.Bugs_--enable-languages=c,c++,fortran,objc,obj-c++
>  
> --prefix=/usr --program-suffix=-4.6 --enable-shared 
> --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib 
> --without-included-gettext --enable-threads=posix 
> --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib 
> --enable-nls --with-sysroot=/ --enable-clocale=gnu 
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
> --enable-gnu-unique-object --enable-plugin --enable-objc-gc 
> --disable-werror --with-arch-32=i686 --with-tune=generic 
> --enable-checking=release --build=x86_64-linux-gnu 
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> …
> ….
> ..
> bin/bash ../libtool --tag=CC --mode=link gcc -Wall -Wsign-compare 
> -I../include -DIPMI_CHECK_LOCKS -g -O2 -rdynamic 
> ../unix/libOpenIPMIposix.la -o ipmi_sim ipmi_sim.o emu.o emu_cmd.o 
> -lpopt libIPMIlanserv.la
> libtool: link: gcc -Wall -Wsign-compare -I../include 
> -DIPMI_CHECK_LOCKS -g -O2 -rdynamic -o .libs/ipmi_sim ipmi_sim.o emu.o 
> emu_cmd.o ../unix/.libs/libOpenIPMIposix.so 
> /usr/lib/x86_64-linux-gnu/libpopt.so ./.libs/libIPMIlanserv.so 
> -Wl,-rpath -Wl,/home/jab/OpenIPMI/opt/lib
> ipmi_sim.o: In function `sleeper':
> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:968: 
> undefined reference to `os_handler_alloc_waiter'
> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:974: 
> undefined reference to `os_handler_waiter_wait'
> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:975: 
> undefined reference to `os_handler_waiter_release'
> ipmi_sim.o: In function `main':
> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:1190: 
> undefined reference to `os_handler_alloc_waiter_factory'
> collect2: ld returned 1 exit status
> make[3]: *** [ipmi_sim] Error 1
> make[3]: Leaving directory 
> `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1'
> make: *** [all] Error 2
> Thanks,
> Rishi
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 12.04

[Corey Minyard]

Dang, one more button to press on Sourceforge.  It should be there now.

I'm not sure what you mean by distribution.  I don't do anything for 
distributions, that's done by the distribution maintainers. There are 
too many for me to handle.

-corey

On 08/30/2013 02:12 PM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> I couldn't see rc3 yet. Can you please send me the location for download.
> Also, please send me the pointer to the distribution for ubuntu 12.04.
>
> Thanks,
> Rishi
>
>
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, August 30, 2013 10:45 AM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 
> 12.04
>
> Sorry, I missed something there.  There is an rc3 version up now, can you try 
> that?
>
> -corey
>
> On 08/30/2013 12:20 PM, Rishi Kaundinya Mutnuru wrote:
>> I got following error with rc2.
>>
>> /bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
>> -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo 
>> -MD -MP -MF .deps/string.Tpo -c -o string.lo string.c
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare
>> -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo -MD -MP -MF
>> .deps/string.Tpo -c string.c  -fPIC -DPIC -o .libs/string.o
>> string.c:56:34: fatal error: OpenIPMI/ipmi_string.h: No such file or
>> directory compilation terminated.
>> make[2]: *** [string.lo] Error 1
>> make[2]: Leaving directory `/home/jab/OpenIPMI2/OpenIPMI-2.0.20-rc2/utils'
>>
>> -Original Message-
>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>> Sent: Friday, August 30, 2013 6:19 AM
>> To: Rishi Kaundinya Mutnuru
>> Cc: openipmi-developer@lists.sourceforge.net
>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>> ubntu 12.04
>>
>> I just uploaded an rc2 version, can you try that?
>>
>> Thanks,
>>
>> -corey
>>
>> On 08/30/2013 12:46 AM, Rishi Kaundinya Mutnuru wrote:
>>> Hi,
>>> I have downladed OpenIPMI-2.0.20-rc1 and tried using for developing a
>>> hardware monitoring tool.
>>> I am facing
>>> compilation issues on ubuntu 12.04 host. I am snipping the error
>>> below with the system details.
>>> Highly appreciate your quick response as this critical for our work.
>>> 
>>> $uname -a
>>> Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012
>>> x86_64 x86_64 x86_64 GNU/Linux
>>> $ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description: Ubuntu 12.04.3 LTS
>>> Release: 12.04
>>> Codename: precise
>>> _jab@__x__:~/OpenIPMI/OpenIPMI-2.0.20-rc1$_
>>> <mailto:jab@nunez-jab:%7E/OpenIPMI/OpenIPMI-2.0.20-rc1$>gcc -v Using
>>> built-in specs.
>>> COLLECT_GCC=/usr/bin/gcc-4.6.real
>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
>>> Target: x86_64-linux-gnu
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
>>> 4.6.3-1ubuntu5'
>>> --with-bugurl=_file:///usr/share/doc/gcc-4.6/README.Bugs_--enable-lan
>>> g uages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>>> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
>>> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
>>> --enable-threads=posix
>>> --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib
>>> --enable-nls --with-sysroot=/ --enable-clocale=gnu
>>> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>>> --enable-gnu-unique-object --enable-plugin --enable-objc-gc
>>> --disable-werror --with-arch-32=i686 --with-tune=generic
>>> --enable-checking=release --build=x86_64-linux-gnu
>>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix
>>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ... 
>>> ..
>>> bin/bash ../libtool --tag=CC --mode=link gcc -Wall -Wsign-compare
>>> -I../include -DIPMI_CHECK_LOCKS -g -O2 -rdynamic
>>> ../unix/libOpenIPMIposix.la -o ipmi_sim ipmi_sim.o emu.o emu_cmd.o
>>> -lpopt libIPMIlanserv.la
>>> libtool: link: gcc -Wall -Wsign-compare -I../include
>>> -DIPMI_CHECK_LOCKS -g -O2 -rdynamic -o .libs/ipmi_sim ipmi_sim.o
>>> emu.o emu_cmd.o ../unix/.libs/libOpenIPMIposix.so
>>> /usr/lib/x86_64-linux-gnu/libpopt.so ./.libs/libIPMIlanserv.so
>>> -Wl,-r

Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 12.04

[Corey Minyard]

On 08/30/2013 02:59 PM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> I still didn't see rc3. What I mean of distribution  is either  rpm or 
> library/tools compiled for ubuntin12.04.

rc3 should be there, I just checked again.  You are looking at 
http://sourceforge.net/projects/openipmi/files/OpenIPMI%202.0%20Library/ ?

I don't do RPMs or debs or anything like that.  That means I'd have to 
have a boatload of distros and do a bunch of work each release. That's 
really not feasible.

-corey

> Thank you very much,
> Regards,
> Rishi
>
>
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, August 30, 2013 12:34 PM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 
> 12.04
>
> Dang, one more button to press on Sourceforge.  It should be there now.
>
> I'm not sure what you mean by distribution.  I don't do anything for 
> distributions, that's done by the distribution maintainers. There are too 
> many for me to handle.
>
> -corey
>
> On 08/30/2013 02:12 PM, Rishi Kaundinya Mutnuru wrote:
>> Hi Corey,
>> I couldn't see rc3 yet. Can you please send me the location for download.
>> Also, please send me the pointer to the distribution for ubuntu 12.04.
>>
>> Thanks,
>> Rishi
>>
>>
>> -Original Message-
>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>> Sent: Friday, August 30, 2013 10:45 AM
>> To: Rishi Kaundinya Mutnuru
>> Cc: openipmi-developer@lists.sourceforge.net
>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>> ubntu 12.04
>>
>> Sorry, I missed something there.  There is an rc3 version up now, can you 
>> try that?
>>
>> -corey
>>
>> On 08/30/2013 12:20 PM, Rishi Kaundinya Mutnuru wrote:
>>> I got following error with rc2.
>>>
>>> /bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
>>> -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo 
>>> -MD -MP -MF .deps/string.Tpo -c -o string.lo string.c
>>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare
>>> -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo -MD -MP -MF
>>> .deps/string.Tpo -c string.c  -fPIC -DPIC -o .libs/string.o
>>> string.c:56:34: fatal error: OpenIPMI/ipmi_string.h: No such file or
>>> directory compilation terminated.
>>> make[2]: *** [string.lo] Error 1
>>> make[2]: Leaving directory `/home/jab/OpenIPMI2/OpenIPMI-2.0.20-rc2/utils'
>>>
>>> -Original Message-
>>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>>> Sent: Friday, August 30, 2013 6:19 AM
>>> To: Rishi Kaundinya Mutnuru
>>> Cc: openipmi-developer@lists.sourceforge.net
>>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>>> ubntu 12.04
>>>
>>> I just uploaded an rc2 version, can you try that?
>>>
>>> Thanks,
>>>
>>> -corey
>>>
>>> On 08/30/2013 12:46 AM, Rishi Kaundinya Mutnuru wrote:
>>>> Hi,
>>>> I have downladed OpenIPMI-2.0.20-rc1 and tried using for developing
>>>> a hardware monitoring tool.
>>>> I am facing
>>>> compilation issues on ubuntu 12.04 host. I am snipping the error
>>>> below with the system details.
>>>> Highly appreciate your quick response as this critical for our work.
>>>> 
>>>> $uname -a
>>>> Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012
>>>> x86_64 x86_64 x86_64 GNU/Linux
>>>> $ lsb_release -a
>>>> No LSB modules are available.
>>>> Distributor ID: Ubuntu
>>>> Description: Ubuntu 12.04.3 LTS
>>>> Release: 12.04
>>>> Codename: precise
>>>> _jab@__x__:~/OpenIPMI/OpenIPMI-2.0.20-rc1$_
>>>> <mailto:jab@nunez-jab:%7E/OpenIPMI/OpenIPMI-2.0.20-rc1$>gcc -v Using
>>>> built-in specs.
>>>> COLLECT_GCC=/usr/bin/gcc-4.6.real
>>>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
>>>> Target: x86_64-linux-gnu
>>>> Configured with: ../src/configure -v
>>>> --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5'
>>>> --with-bugurl=_file:///usr/share/doc/gcc-4.6/README.Bugs_--enable-la
>>>> n g uages=c,c++,fortran,objc,obj-c++ --prefix=/usr
>>>> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
>>>

Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 12.04

[Corey Minyard]

The best way to get the changes is the git tree at 
https://sourceforge.net/p/openipmi/code/ci/master/tree/

-corey

On 08/30/2013 04:30 PM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> I was able to build rc3 on ubuntu 12.04. Appreciate your hard work and quick 
> response
> and this will be useful for many developers across globe.
> I am curious to know the diff and patch for this. Can you point me the diff 
> or fix done.
>
> Thanks,
> Rishi
>
>
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, August 30, 2013 1:55 PM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 
> 12.04
>
> On 08/30/2013 02:59 PM, Rishi Kaundinya Mutnuru wrote:
>> Hi Corey,
>> I still didn't see rc3. What I mean of distribution  is either  rpm or 
>> library/tools compiled for ubuntin12.04.
> rc3 should be there, I just checked again.  You are looking at 
> http://sourceforge.net/projects/openipmi/files/OpenIPMI%202.0%20Library/ ?
>
> I don't do RPMs or debs or anything like that.  That means I'd have to have a 
> boatload of distros and do a bunch of work each release. That's really not 
> feasible.
>
> -corey
>
>> Thank you very much,
>> Regards,
>> Rishi
>>
>>
>> -Original Message-
>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>> Sent: Friday, August 30, 2013 12:34 PM
>> To: Rishi Kaundinya Mutnuru
>> Cc: openipmi-developer@lists.sourceforge.net
>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>> ubntu 12.04
>>
>> Dang, one more button to press on Sourceforge.  It should be there now.
>>
>> I'm not sure what you mean by distribution.  I don't do anything for 
>> distributions, that's done by the distribution maintainers. There are too 
>> many for me to handle.
>>
>> -corey
>>
>> On 08/30/2013 02:12 PM, Rishi Kaundinya Mutnuru wrote:
>>> Hi Corey,
>>> I couldn't see rc3 yet. Can you please send me the location for download.
>>> Also, please send me the pointer to the distribution for ubuntu 12.04.
>>>
>>> Thanks,
>>> Rishi
>>>
>>>
>>> -Original Message-
>>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>>> Sent: Friday, August 30, 2013 10:45 AM
>>> To: Rishi Kaundinya Mutnuru
>>> Cc: openipmi-developer@lists.sourceforge.net
>>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>>> ubntu 12.04
>>>
>>> Sorry, I missed something there.  There is an rc3 version up now, can you 
>>> try that?
>>>
>>> -corey
>>>
>>> On 08/30/2013 12:20 PM, Rishi Kaundinya Mutnuru wrote:
>>>> I got following error with rc2.
>>>>
>>>> /bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
>>>> -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo 
>>>> -MD -MP -MF .deps/string.Tpo -c -o string.lo string.c
>>>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare
>>>> -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo -MD -MP -MF
>>>> .deps/string.Tpo -c string.c  -fPIC -DPIC -o .libs/string.o
>>>> string.c:56:34: fatal error: OpenIPMI/ipmi_string.h: No such file or
>>>> directory compilation terminated.
>>>> make[2]: *** [string.lo] Error 1
>>>> make[2]: Leaving directory `/home/jab/OpenIPMI2/OpenIPMI-2.0.20-rc2/utils'
>>>>
>>>> -Original Message-
>>>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>>>> Sent: Friday, August 30, 2013 6:19 AM
>>>> To: Rishi Kaundinya Mutnuru
>>>> Cc: openipmi-developer@lists.sourceforge.net
>>>> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in
>>>> ubntu 12.04
>>>>
>>>> I just uploaded an rc2 version, can you try that?
>>>>
>>>> Thanks,
>>>>
>>>> -corey
>>>>
>>>> On 08/30/2013 12:46 AM, Rishi Kaundinya Mutnuru wrote:
>>>>> Hi,
>>>>> I have downladed OpenIPMI-2.0.20-rc1 and tried using for developing
>>>>> a hardware monitoring tool.
>>>>> I am facing
>>>>> compilation issues on ubuntu 12.04 host. I am snipping the error
>>>>> below with the system details.
>>>>> Highly appreciate your quick response as this critical

Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 12.04

[Corey Minyard]

Sorry, I missed something there.  There is an rc3 version up now, can 
you try that?

-corey

On 08/30/2013 12:20 PM, Rishi Kaundinya Mutnuru wrote:
> I got following error with rc2.
>
> /bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..
> -Wall -Wsign-compare -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo -MD 
> -MP -MF .deps/string.Tpo -c -o string.lo string.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wsign-compare 
> -I../include -DIPMI_CHECK_LOCKS -g -O2 -MT string.lo -MD -MP -MF 
> .deps/string.Tpo -c string.c  -fPIC -DPIC -o .libs/string.o
> string.c:56:34: fatal error: OpenIPMI/ipmi_string.h: No such file or directory
> compilation terminated.
> make[2]: *** [string.lo] Error 1
> make[2]: Leaving directory `/home/jab/OpenIPMI2/OpenIPMI-2.0.20-rc2/utils'
>
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, August 30, 2013 6:19 AM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Compilation error with OpenIPMI in ubntu 
> 12.04
>
> I just uploaded an rc2 version, can you try that?
>
> Thanks,
>
> -corey
>
> On 08/30/2013 12:46 AM, Rishi Kaundinya Mutnuru wrote:
>> Hi,
>> I have downladed OpenIPMI-2.0.20-rc1 and tried using for developing a
>> hardware monitoring tool.
>> I am facing
>> compilation issues on ubuntu 12.04 host. I am snipping the error below
>> with the system details.
>> Highly appreciate your quick response as this critical for our work.
>> 
>> $uname -a
>> Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012
>> x86_64 x86_64 x86_64 GNU/Linux
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 12.04.3 LTS
>> Release: 12.04
>> Codename: precise
>> _jab@__x__:~/OpenIPMI/OpenIPMI-2.0.20-rc1$_
>> <mailto:jab@nunez-jab:%7E/OpenIPMI/OpenIPMI-2.0.20-rc1$>gcc -v Using
>> built-in specs.
>> COLLECT_GCC=/usr/bin/gcc-4.6.real
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
>> Target: x86_64-linux-gnu
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
>> 4.6.3-1ubuntu5'
>> --with-bugurl=_file:///usr/share/doc/gcc-4.6/README.Bugs_--enable-lang
>> uages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6
>> --enable-shared --enable-linker-build-id --with-system-zlib
>> --libexecdir=/usr/lib --without-included-gettext
>> --enable-threads=posix
>> --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib
>> --enable-nls --with-sysroot=/ --enable-clocale=gnu
>> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>> --enable-gnu-unique-object --enable-plugin --enable-objc-gc
>> --disable-werror --with-arch-32=i686 --with-tune=generic
>> --enable-checking=release --build=x86_64-linux-gnu
>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix
>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ... 
>> ..
>> bin/bash ../libtool --tag=CC --mode=link gcc -Wall -Wsign-compare
>> -I../include -DIPMI_CHECK_LOCKS -g -O2 -rdynamic
>> ../unix/libOpenIPMIposix.la -o ipmi_sim ipmi_sim.o emu.o emu_cmd.o
>> -lpopt libIPMIlanserv.la
>> libtool: link: gcc -Wall -Wsign-compare -I../include
>> -DIPMI_CHECK_LOCKS -g -O2 -rdynamic -o .libs/ipmi_sim ipmi_sim.o emu.o
>> emu_cmd.o ../unix/.libs/libOpenIPMIposix.so
>> /usr/lib/x86_64-linux-gnu/libpopt.so ./.libs/libIPMIlanserv.so
>> -Wl,-rpath -Wl,/home/jab/OpenIPMI/opt/lib
>> ipmi_sim.o: In function `sleeper':
>> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:968:
>> undefined reference to `os_handler_alloc_waiter'
>> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:974:
>> undefined reference to `os_handler_waiter_wait'
>> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:975:
>> undefined reference to `os_handler_waiter_release'
>> ipmi_sim.o: In function `main':
>> /home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv/ipmi_sim.c:1190:
>> undefined reference to `os_handler_alloc_waiter_factory'
>> collect2: ld returned 1 exit status
>> make[3]: *** [ipmi_sim] Error 1
>> make[3]: Leaving directory
>> `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv'
>> make[2]: *** [all-recursive] Error 1
>> make[2]: Leaving directory
>> `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1/lanserv'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/home/jab/OpenIPMI/OpenIPMI-2.0.20-rc1'
>> make: *** [all] Error 2
>&

Re: [Openipmi-developer] Power Supply failed/normal ipmi event in OpenIPMI

[Corey Minyard]

There is sample code in the "samples" directory that shows a lot of 
this.  If you just want to periodically query a single sensor, openipmi 
is probably overkill and ipmitool would be simpler.  If you want to 
continuously monitor a bunch of sensors or a large number of systems, 
the openipmi is probably the better tool.

Also, events are something specific in IPMI.  Do you mean events, or do 
you mean the occurrence of a failure?

-corey

On 09/06/2013 06:37 PM, Rishi Kaundinya Mutnuru wrote:
> Hi All,
> I am trying to find out power supply failed and power supply normal 
> IPMI events for reporting.
> The sensor type is IPMI_SENSOR_TYPE_POWER_SUPPLY. Can you please point 
> me a skeleton code,
> How I can achieve this.
> Thanks,
> Rishi
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Power Supply failed/normal ipmi event in OpenIPMI

[Corey Minyard]

On 09/06/2013 10:39 PM, Rishi Kaundinya Mutnuru wrote:
> I mean occurance of a failure. I searched in samples directory, but couldn't 
> find specific code
> Of sensor type IPMI_SENSOR_TYPE_POWER_SUPPLY.Can ypu please point me 
> specifically.

Well, there's not any, those are general samples to show how things 
work.  There is a sample program that simply goes through all the 
entities and sensors and prints everything about them.  You could adapt 
that one to look for the specific entity then sensor, then when you find 
it get the information you want.

-corey

>
> Thanks,
> Rishi
>
> -----Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Friday, September 06, 2013 8:21 PM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Power Supply failed/normal ipmi event in 
> OpenIPMI
>
> There is sample code in the "samples" directory that shows a lot of this.  If 
> you just want to periodically query a single sensor, openipmi is probably 
> overkill and ipmitool would be simpler.  If you want to continuously monitor 
> a bunch of sensors or a large number of systems, the openipmi is probably the 
> better tool.
>
> Also, events are something specific in IPMI.  Do you mean events, or do you 
> mean the occurrence of a failure?
>
> -corey
>
> On 09/06/2013 06:37 PM, Rishi Kaundinya Mutnuru wrote:
>> Hi All,
>> I am trying to find out power supply failed and power supply normal
>> IPMI events for reporting.
>> The sensor type is IPMI_SENSOR_TYPE_POWER_SUPPLY. Can you please point
>> me a skeleton code, How I can achieve this.
>> Thanks,
>> Rishi
>>
>
>
>


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Issue with ipmi_open_domain function

[Corey Minyard]

On 09/10/2013 04:09 PM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> Can you tell me how do I get the message trace.

Include ipmi_debug.h and add:

DEBUG_MSG_ENABLE();

to your code before you init.

-corey
>
> Regards,
> Rishi
>
>
> -Original Message-----
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Tuesday, September 10, 2013 2:07 PM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Issue with ipmi_open_domain function
>
> It won't call done until, well, it's done. That may take a while, and since 
> it can't get the SDRs, it's going to fail and never be done. There is another 
> callback for connection up/down. But there's something going on with your 
> BMC, either something else is getting SDRs all the time, or there's a bug 
> someplace.
>
> Can you get a message trace to see what is going on?
>
> -corey
>
> On 09/10/2013 02:49 PM, Rishi Kaundinya Mutnuru wrote:
>> And I got one of the errors as follows.
>>
>> EINF: (f.f)(m,0) sdr.c(handle_sdr_data): Lost reservation too many
>> times trying to fetch SDRs
>>
>> WARN: domain.c(sdr_handler): Could not get main SDRs, error 0xb
>>
>> Thanks,
>> Rishi
>>
>> *From:*Rishi Kaundinya Mutnuru [mailto:rkmutn...@juniper.net]
>> *Sent:* Tuesday, September 10, 2013 12:42 PM
>> *To:* openipmi-developer@lists.sourceforge.net
>> *Subject:* [Openipmi-developer] Issue with ipmi_open_domain function
>>
>> Hi All,
>>
>> After looking at the sample code, I have written a test code like
>> below and found that
>>
>> My routine "ipmicb_setup_done" is never invoked.
>>
>> 
>>
>> ipmi_init(os);
>>
>> rv = ipmi_smi_setup_con(0, os, NULL, &sentbl.st_ipmi_con);
>>
>> if (rv) {
>>
>> system("echo Inside jabsentbl_init 1>> /tmp/Rishi");
>>
>> ipmi_shutdown();
>>
>> return -1;
>>
>> }
>>
>> rv = ipmi_open_domain("", &sentbl.st_ipmi_con, 1,
>>
>> */ipmicb_setup_done/*, NULL, NULL, NULL, NULL, 0, NULL);
>>
>> if (rv) {
>>
>> system("echo Inside jabsentbl_init 2>> /tmp/Rishi");
>>
>> ipmi_shutdown();
>>
>> return -1;
>>
>> }
>>
>> sentbl.st_inited = TRUE;
>>
>> 
>>
>> Can you please throw some lights why the "ipmicb_setup_done" is not
>> invoked. Also, let me know if there is a workaround
>>
>> On how I can register the event handler.
>>
>> Thanks,
>> Rishi
>>
>>
>>
>> --
>>  How ServiceNow helps IT people transform IT departments:
>> 1. Consolidate legacy IT systems to a single system of record for IT
>> 2. Standardize and globalize service processes across IT 3. Implement
>> zero-touch automation to replace manual, redundant tasks
>> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.c
>> lktrk
>>
>>
>> ___
>> Openipmi-developer mailing list
>> Openipmi-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>
>
>


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Issue with ipmi_open_domain function

[Corey Minyard]

It won't call done until, well, it's done. That may take a while, and 
since it can't get the SDRs, it's going to fail and never be done. There 
is another callback for connection up/down. But there's something going 
on with your BMC, either something else is getting SDRs all the time, or 
there's a bug someplace.

Can you get a message trace to see what is going on?

-corey

On 09/10/2013 02:49 PM, Rishi Kaundinya Mutnuru wrote:
>
> And I got one of the errors as follows.
>
> EINF: (f.f)(m,0) sdr.c(handle_sdr_data): Lost reservation too many 
> times trying to fetch SDRs
>
> WARN: domain.c(sdr_handler): Could not get main SDRs, error 0xb
>
> Thanks,
> Rishi
>
> *From:*Rishi Kaundinya Mutnuru [mailto:rkmutn...@juniper.net]
> *Sent:* Tuesday, September 10, 2013 12:42 PM
> *To:* openipmi-developer@lists.sourceforge.net
> *Subject:* [Openipmi-developer] Issue with ipmi_open_domain function
>
> Hi All,
>
> After looking at the sample code, I have written a test code like 
> below and found that
>
> My routine “ipmicb_setup_done” is never invoked.
>
> 
>
> ipmi_init(os);
>
> rv = ipmi_smi_setup_con(0, os, NULL, &sentbl.st_ipmi_con);
>
> if (rv) {
>
> system("echo Inside jabsentbl_init 1>> /tmp/Rishi");
>
> ipmi_shutdown();
>
> return -1;
>
> }
>
> rv = ipmi_open_domain("", &sentbl.st_ipmi_con, 1,
>
> */ipmicb_setup_done/*, NULL, NULL, NULL, NULL, 0, NULL);
>
> if (rv) {
>
> system("echo Inside jabsentbl_init 2>> /tmp/Rishi");
>
> ipmi_shutdown();
>
> return -1;
>
> }
>
> sentbl.st_inited = TRUE;
>
> 
>
> Can you please throw some lights why the “ipmicb_setup_done” is not 
> invoked. Also, let me know if there is a workaround
>
> On how I can register the event handler.
>
> Thanks,
> Rishi
>
>
>
> --
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Issue with ipmi_open_domain function

[Corey Minyard]

It goes the the standard log output, as debug logs.

-corey

On 09/10/2013 06:12 PM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> Where does the messages go after I keep DEBUG_MSG_ENABLE in my daemon?
>
> Thanks,
> Rishi
>
> -Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com]
> Sent: Tuesday, September 10, 2013 2:19 PM
> To: Rishi Kaundinya Mutnuru
> Cc: openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Issue with ipmi_open_domain function
>
> On 09/10/2013 04:09 PM, Rishi Kaundinya Mutnuru wrote:
>> Hi Corey,
>> Can you tell me how do I get the message trace.
> Include ipmi_debug.h and add:
>
> DEBUG_MSG_ENABLE();
>
> to your code before you init.
>
> -corey
>> Regards,
>> Rishi
>>
>>
>> -Original Message-
>> From: Corey Minyard [mailto:tcminy...@gmail.com]
>> Sent: Tuesday, September 10, 2013 2:07 PM
>> To: Rishi Kaundinya Mutnuru
>> Cc: openipmi-developer@lists.sourceforge.net
>> Subject: Re: [Openipmi-developer] Issue with ipmi_open_domain function
>>
>> It won't call done until, well, it's done. That may take a while, and since 
>> it can't get the SDRs, it's going to fail and never be done. There is 
>> another callback for connection up/down. But there's something going on with 
>> your BMC, either something else is getting SDRs all the time, or there's a 
>> bug someplace.
>>
>> Can you get a message trace to see what is going on?
>>
>> -corey
>>
>> On 09/10/2013 02:49 PM, Rishi Kaundinya Mutnuru wrote:
>>> And I got one of the errors as follows.
>>>
>>> EINF: (f.f)(m,0) sdr.c(handle_sdr_data): Lost reservation too many
>>> times trying to fetch SDRs
>>>
>>> WARN: domain.c(sdr_handler): Could not get main SDRs, error 0xb
>>>
>>> Thanks,
>>> Rishi
>>>
>>> *From:*Rishi Kaundinya Mutnuru [mailto:rkmutn...@juniper.net]
>>> *Sent:* Tuesday, September 10, 2013 12:42 PM
>>> *To:* openipmi-developer@lists.sourceforge.net
>>> *Subject:* [Openipmi-developer] Issue with ipmi_open_domain function
>>>
>>> Hi All,
>>>
>>> After looking at the sample code, I have written a test code like
>>> below and found that
>>>
>>> My routine "ipmicb_setup_done" is never invoked.
>>>
>>> 
>>>
>>> ipmi_init(os);
>>>
>>> rv = ipmi_smi_setup_con(0, os, NULL, &sentbl.st_ipmi_con);
>>>
>>> if (rv) {
>>>
>>> system("echo Inside jabsentbl_init 1>> /tmp/Rishi");
>>>
>>> ipmi_shutdown();
>>>
>>> return -1;
>>>
>>> }
>>>
>>> rv = ipmi_open_domain("", &sentbl.st_ipmi_con, 1,
>>>
>>> */ipmicb_setup_done/*, NULL, NULL, NULL, NULL, 0, NULL);
>>>
>>> if (rv) {
>>>
>>> system("echo Inside jabsentbl_init 2>> /tmp/Rishi");
>>>
>>> ipmi_shutdown();
>>>
>>> return -1;
>>>
>>> }
>>>
>>> sentbl.st_inited = TRUE;
>>>
>>> 
>>>
>>> Can you please throw some lights why the "ipmicb_setup_done" is not
>>> invoked. Also, let me know if there is a workaround
>>>
>>> On how I can register the event handler.
>>>
>>> Thanks,
>>> Rishi
>>>
>>>
>>>
>>> -
>>> -
>>>  How ServiceNow helps IT people transform IT departments:
>>> 1. Consolidate legacy IT systems to a single system of record for IT
>>> 2. Standardize and globalize service processes across IT 3. Implement
>>> zero-touch automation to replace manual, redundant tasks
>>> http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.
>>> c
>>> lktrk
>>>
>>>
>>> ___
>>> Openipmi-developer mailing list
>>> Openipmi-developer@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>>
>>
>
>
>


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] ipmi driver git tree

[Corey Minyard]

On 09/11/2013 12:41 PM, Tony Camuso wrote:
> Corey,
>
> Is there a git tree for the ipmi driver I can fetch?
>
> Thanks,
> Tony
Yes, it's on Sourceforge, the web page for it is 
https://sourceforge.net/p/openipmi/linux-ipmi/ci/master/tree/

master-ipmi-rebase is the branch I rebase to track k.org.

The per-version branches are named v-ipmi and will not rebase.

The master-ipmi-rebase branch only contains the serial interface driver 
and the I2C interface driver at the moment.  Everything that was 
destined for k.org is in at the moment.

-corey

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] ipmi driver git tree

[Corey Minyard]

On 09/11/2013 01:34 PM, Tony Camuso wrote:
> On 09/11/2013 01:54 PM, Corey Minyard wrote:
>> On 09/11/2013 12:41 PM, Tony Camuso wrote:
>>> Corey,
>>>
>>> Is there a git tree for the ipmi driver I can fetch?
>>>
>>> Thanks,
>>> Tony
>> Yes, it's on Sourceforge, the web page for it is 
>> https://sourceforge.net/p/openipmi/linux-ipmi/ci/master/tree/
>>
>> master-ipmi-rebase is the branch I rebase to track k.org.
>>
>> The per-version branches are named v-ipmi and will not rebase.
>>
>> The master-ipmi-rebase branch only contains the serial interface driver and 
>> the I2C interface driver at the moment.  Everything that was destined for 
>> k.org is in at the moment.
>>
>> -corey
> OK, the reason I asked was to see if Lv Zheng's patch was gonna make it into 
> 3.12.
> http://www.kernelhub.org/?msg=298219&p=2, 02/13 submitted 2013-07-23.
>
>

Ah.  Yes, and you resent that a little later.  The ownership of 
acpi_ipmi is kind of fuzzy, I guess.  I really didn't know it fell into 
my hands to handle this, I assumed it belonged to the acpi maintainer 
since it's in that directory.

-corey

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] OpenIPMI question

[Corey Minyard]

Sorry, I didn't respond to an earlier message you sent.

That should be mostly fine. You need a log handlers, and the output of
that may tell you what is going wrong.

-corey

On 09/15/2013 01:29 AM, Rishi Kaundinya Mutnuru wrote:
> Hi Corey,
> I am invoking the OpenIPMI routines by linking the libOpenIPMI.a to my
> C++ code.
> I have kept the calling code “extern “C”” logic. Do you know whether I
> need to anything
> Else to link the OpenIPMI libraries to my c++ code.
> Somehow the function I register to “ipmi_open_domain” never got
> invoked and I am stuck there.
> Please let me know whether I need to anything else in my daemon.
> os_handler_t *osfns;
> int
> sentbl_init (os_handler_t *os)
> {
> int rv;
> assert(os && !sentbl.st_inited);
> DEBUG_MSG_ENABLE();
> ipmi_init(os);
> rv = ipmi_smi_setup_con(0, os, NULL, &sentbl.st_ipmi_con);
> if (rv) {
> ipmi_shutdown();
> return -1;
> }
> rv = ipmi_open_domain("", &sentbl.st_ipmi_con, 1,
> ipmicb_setup_done, NULL, NULL, NULL, NULL, 0, NULL);
> àipmicb_setup_done never invoked
> if (rv) {
> ipmi_shutdown();
> return -1;
> }
> sentbl.st_inited = TRUE;
> return 0;
> }
> Main()
> {
> //IPMI handler
> osfns = ipmi_posix_setup_os_handler();
> if (!osfns) {
> }
> While(1) {
> ….
> if (osfns) {
> osfns->perform_one_op(osfns, tvp);
> }
> }
> Please let me know if I need to add anything else to this code.
> Thanks,
> Rishi


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Should quirks to support broken hardware be upstreamed?

[Corey Minyard]

Sorry for the long delay on this.  I will certainly take such patches. 
If you can auto-detect and develop white/black lists, that would be even
better.

Thanks,

-corey

On 08/28/2013 12:31 AM, Nikita Yushchenko wrote:
> Hello
>
> Hardware I currently deal with has issues that force me to patch openipmi 
> library to make it working.
>
> - RMCP packets sent by BMC have broken session sequence numbers in session 
> header - so I had to comment out call to check_20_session_seq_num() from 
> handle_rmcpp_recv() to avoid openipmi dropping all incoming packets,
> [note that ipmitool does not validate session sequence numbers, thus works 
> with this hardware]
>
> - BMC misbehaves badly (session gets broken) if it gets "Get Device SDR" 
> command with read size set to something larger that 14, openipmi tries 16 
> by default. So I had to alter how sdrs->fetch_size is initialized in 
> ipmi_sdr_info_alloc().
>
> I can create openipmi patches that will add some new flags enabling 
> workarounds for these hardware issues. Will you accept such patches into 
> upstream?
>
> Nikita


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Better connection error handling in openipmi?

[Corey Minyard]

On 08/28/2013 09:07 AM, Nikita Yushchenko wrote:
> Hi
>
> I'm trying to handle 'invalid user' and 'invalid password' errors in 
> openipmi-based application.
>
> I've found how I can detect 'invalid user'.In this case, error passed to 
> connection callback is either 0x181 or 0x20d, depending on if 
> RMCP+ is used or not. First originates from 0x81 completion code returned 
> by Get Session Channenge command, and second is RMCP 'unauthorized name' 
> error.
>
> However, for 'invalid password' situation is worse.
> Without RMCP+, there is just timeout. Perhaps hardware issue.

As Albert mentioned, most BMCs will just drop packets without proper
authentication.

> With RMCP+, there is EINVAL, originatiing from
>
> if (memcmp(data+40, integ_data, rinfo->key_len) != 0)
>   return EINVAL;
>
> in rakp_hmac_c2().
>
> I suggest to replace this EINVAL with something other, to let application 
> detect and handle invalid login credentials. Maybe EACCES, or some 
> specific error code.
>
>
> Other very questionable EINVAL is where ''Requested authentication not 
> supported' message is logged in auth_cap_done().  Some better value could 
> be returned here, maybe ENOTSUP.
>
> What do you think?

I'm fine with changing both of these.

-corey

>
> Nikita


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Better connection error handling in openipmi?

[Corey Minyard]

Applied, thank you.

-corey

On 09/24/2013 11:21 PM, Nikita Yushchenko wrote:
>>> With RMCP+, there is EINVAL, originatiing from
>>>
>>> if (memcmp(data+40, integ_data, rinfo->key_len) != 0)
>>> return EINVAL;
>>>
>>> in rakp_hmac_c2().
>>>
>>> I suggest to replace this EINVAL with something other, to let
>>> application detect and handle invalid login credentials. Maybe EACCES,
>>> or some specific error code.
>>>
>>>
>>> Other very questionable EINVAL is where ''Requested authentication not
>>> supported' message is logged in auth_cap_done().  Some better value
>>> could be returned here, maybe ENOTSUP.
>>>
>>> What do you think?
>> I'm fine with changing both of these.
>>
>> -corey
> Hi
>
> Attached is a patch that I currently have in my tree to detect bad password 
> errors.
>
> For the rest, I currently only have dirty fixes (i.e. that fixes this 
> hardware by breaking other). I will submit clean patches if/when those are 
> ready.
>
> Nikita
>


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] timing issues

[Corey Minyard]

Got it, thanks.  I added a header to the new file.

-corey

On 10/10/2013 05:33 AM, Lashenko, George wrote:
> Dear Developers,
>
> I've encountered a problem in OpenIPMI something I see as a bug, the issue is 
> that the library uses gettimeofday as its source for creating timeouts
>
> this can cause a problem if some action is registered and the date of the 
> machine is changed (backwards) this way the selector will take much longer
>
> to call the action to happen. I'm sending you a patch that I use in my 
> system, it speaks for itself, please take a look and tell me what you think 
> (basicly
>
> I changed the the use of gettimeofday --> clock(MONOTONIC_CLOCK))
>
> Thanks a lot,
> George Lashenko 
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] timing issues

[Corey Minyard]

Actually, this patch was broken.  It didn't pass the test.  You have to
modify the condition variables to use monotonic time, or condwait will
be broken.

I've completely rewritten this patch, but it was an important change and
needed to be done.  Changes are now in git.

-corey

On 10/10/2013 05:33 AM, Lashenko, George wrote:
> Dear Developers,
>
> I've encountered a problem in OpenIPMI something I see as a bug, the issue is 
> that the library uses gettimeofday as its source for creating timeouts
>
> this can cause a problem if some action is registered and the date of the 
> machine is changed (backwards) this way the selector will take much longer
>
> to call the action to happen. I'm sending you a patch that I use in my 
> system, it speaks for itself, please take a look and tell me what you think 
> (basicly
>
> I changed the the use of gettimeofday --> clock(MONOTONIC_CLOCK))
>
> Thanks a lot,
> George Lashenko 
>
>
> --
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: remove deprecated IRQF_DISABLED

[Corey Minyard]

Thanks, it's in the queue.

-corey

On 10/12/2013 10:59 PM, Michael Opdenacker wrote:
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker 
> ---
>  drivers/char/ipmi/ipmi_si_intf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 15e4a60..68c5ef5 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -1358,7 +1358,7 @@ static int std_irq_setup(struct smi_info *info)
>   if (info->si_type == SI_BT) {
>   rv = request_irq(info->irq,
>si_bt_irq_handler,
> -  IRQF_SHARED | IRQF_DISABLED,
> +  IRQF_SHARED,
>DEVICE_NAME,
>info);
>   if (!rv)
> @@ -1368,7 +1368,7 @@ static int std_irq_setup(struct smi_info *info)
>   } else
>   rv = request_irq(info->irq,
>si_irq_handler,
> -  IRQF_SHARED | IRQF_DISABLED,
> +  IRQF_SHARED,
>DEVICE_NAME,
>info);
>   if (rv) {


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 00/20] Add an IPMI device to QEMU

[Corey Minyard]

On 11/05/2013 07:56 AM, Michael S. Tsirkin wrote:
> On Wed, May 29, 2013 at 05:07:56PM -0500, miny...@acm.org wrote:
>> I have finally gotten some time to work on this, this series of
>> patches adds an IPMI interface to qemu.  The changes are roughly:
>>
>> patches 01-05 - Add the capability to have a chardev reconnect if
>> the connections fails.  This way, if using an external BMC, qemu
>> will detect the failure and periodically attempt to reconnect.
>> This also adds ways for the device code to get an event on a
>> disconnect and connect so it can handle it properly.  This is
>> probably useful for things besides IPMI.  There are also a few
>> small bugfixes in this.
>>
>> patches 06-14 - Add the IPMI device itself, with an ISA interface
>> for now (PCI and others can also be added easily).
>>
>> patches 15-18 - Add a way to dynamically add content to the ACPI
>> tables, and add the capability to add the IPMI information to the
>> table.
>>
>> Patches 19-20 - Add a way to dynamically add content to the SMBIOS
>> tables, and add an IPMI entry to the table.
>>
> I was pointed at these patches as an example of useful
> functionality that's out of qemu merely for lack of review
> resources. I'd like to help.
>
> Now that we have code to generate ACPI tables
> directly in qemu, this series can be rebased on top of
> that, with no need for new FW CFG entries or bios changes.
>
> If you have the time, pls Cc me on patches and I'll try to
> help shepherd them upstream.
>  
Ok, thanks.  I will make some time this week to get the patches updated
to the current git tree.

-corey

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [Qemu-devel] [PATCH 00/20] Add an IPMI device to QEMU

[Corey Minyard]

On 11/05/2013 10:09 AM, Andreas Färber wrote:
> Hi,
>
> Am 05.11.2013 14:56, schrieb Michael S. Tsirkin:
>> On Wed, May 29, 2013 at 05:07:56PM -0500, miny...@acm.org wrote:
>>> I have finally gotten some time to work on this, this series of
>>> patches adds an IPMI interface to qemu.  The changes are roughly:
>>>
>>> patches 01-05 - Add the capability to have a chardev reconnect if
>>> the connections fails.  This way, if using an external BMC, qemu
>>> will detect the failure and periodically attempt to reconnect.
>>> This also adds ways for the device code to get an event on a
>>> disconnect and connect so it can handle it properly.  This is
>>> probably useful for things besides IPMI.  There are also a few
>>> small bugfixes in this.
>>>
>>> patches 06-14 - Add the IPMI device itself, with an ISA interface
>>> for now (PCI and others can also be added easily).
>>>
>>> patches 15-18 - Add a way to dynamically add content to the ACPI
>>> tables, and add the capability to add the IPMI information to the
>>> table.
>>>
>>> Patches 19-20 - Add a way to dynamically add content to the SMBIOS
>>> tables, and add an IPMI entry to the table.
>>>
>> I was pointed at these patches as an example of useful
>> functionality that's out of qemu merely for lack of review
>> resources. I'd like to help.
>>
>> Now that we have code to generate ACPI tables
>> directly in qemu, this series can be rebased on top of
>> that, with no need for new FW CFG entries or bios changes.
>>
>> If you have the time, pls Cc me on patches and I'll try to
>> help shepherd them upstream.
> Me too, I have IPMI on my radar for 1.8/2.0.
>
> Our use case would be using IPMI tools to boot/reboot/shutdown a guest
> and to access its serial console as done for the physical hosts; we had
> discussed in the past where to locate such a TCP server component,
> whether in QEMU or libvirt - am I interpreting correctly that patch 11
> is preparing an interface to have that as external process now? Or is it
> hidden somewhere in patch 10 or is this unimplemented in this version?

Patch 11 does that, it gives an external interface.  The OpenIPMI
library has a
simulator that will plug in to this interface to provide BMC functions
and an
IPMI LAN interface.

You can do the boot/reboot/shutdown via the normal mechanisms with the
external simulator.  The internal simulator doesn't have an IPMI LAN
interface,
though, so you would need the external interface.

I also have not provided a serial over LAN interface through this
interface.  If
that's what you are looking for, more work would need to be done.

Thanks,

-corey

>
> Also, some of the IPMI acronyms in the commit messages (KCS, BT, ...)
> could use some explanation in the next version. ;)
>
> Regards,
> Andreas
>


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] IPMI kernel driver question

[Corey Minyard]

That shouldn't happen.  Did you deregister the user when you removed the
module?

Actually, that doesn't seem to be it:

 [] ? do_page_fault+0x3e/0xa0
 [] ? page_fault+0x25/0x30
 [] ? misc_register+0x4c/0x170
 [] ? misc_register+0x27/0x170
 [] ? sce_new_smi+0x74/0x10c [ipmi_sce_logger]
 [] ? ipmi_smi_watcher_register+0x121/0x240
[ipmi_msghandler]
 [] ? notifier_call_chain+0x55/0x80
 [] ? ipmi_sce_init+0x0/0x3f [ipmi_sce_logger]

Notice it calls your sce_new_smi code, which calls misc_register, which
fails.  I suspect you didn't remove the misc device registration when
you removed the module.

-corey

On 11/11/2013 06:04 PM, David Bashaw wrote:
> Hello all.
>
> I have been developing a kernel module to log OEM SEL entries.
> I noticed the following problem:
>
> # insmod ipmi_sce_logger.ko
> IPMI sce error logger: sce user created
> IPMI sce error logger: driver initialized
>
> Now rmmod
>
> # rmmod ipmi_sce_logger   
> IPMI sce error logger: ipmi_sce_exit
> #
>
> So far so good. Now insmod a second time.
>
> # insmod ipmi_sce_logger.ko
> BUG: unable to handle kernel paging request at 001e13e8
> IP: [] misc_register+0x4c/0x170
> PGD 42f00a067 PUD 0
> Oops:  [#1] SMP
> last sysfs file:
> /sys/devices/pci:00/:00:0c.0/:02:00.0/host0/port-0:0/expander-0:0/phy-0:0:20/sas_phy/phy-0:0:20/phy_identifier
> CPU 1
> Pid: 12131, comm: insmod Not tainted 2.6.32 #1 empty
> RIP: 0010:[]  []
> misc_register+0x4c/0x170
> RSP: 0018:88042c7b3e78  EFLAGS: 00010283
> RAX: 001e13e7ffe8 RBX: a00b4980 RCX: 001e13e8
> RDX: 0095 RSI: a00ad998 RDI: 81cf1ae0
> RBP: 88042c7b3e88 R08: 00d0 R09: 
> R10:  R11: 0003 R12: a00b4998
> R13: 88042c7b3eb8 R14: a00b4940 R15: 880437c00040
> FS:  7ffb34b37700() GS:88002824()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 001e13e8 CR3: 00042e423000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process insmod (pid: 12131, threadinfo 88042c7b2000, task
> 8804327baab0)
> Stack:
>  88042f8ba440 88042c7b3ea8 88042c7b3e98 a00b4354
> <0> 88042c7b3ef8 a006f4a1 88042c7b3ee8 8169b3e5
> <0> 88042c7b3eb8 88042c7b3eb8 81ca1bc0 
> Call Trace:
>  [] sce_new_smi+0x74/0x10c [ipmi_sce_logger]
>  [] ipmi_smi_watcher_register+0x121/0x240
> [ipmi_msghandler]
>  [] ? notifier_call_chain+0x55/0x80
>  [] ? ipmi_sce_init+0x0/0x3f [ipmi_sce_logger]
>  [] ipmi_sce_init+0x15/0x3f [ipmi_sce_logger]
>  [] do_one_initcall+0x3c/0x1d0
>  [] sys_init_module+0xdf/0x250
>  [] system_call_fastpath+0x16/0x1b
> Code: 81 e8 f9 02 34 00 48 8b 05 62 b0 99 00 8b 13 48 83 e8 18 eb 16
> 66 2e 0f 1f 84 00 00 00 00 00 39 10 0f 84 98 00 00 00 48 8d 41 e8 <48>
> 8b 48 18 48 8d 70 18 48 81 fe 00 1b cf 81 0f 18 09 75 e0 81
> RIP  [] misc_register+0x4c/0x170
>  RSP 
> CR2: 001e13e8
> ---[ end trace 9c1825899c25a062 ]---
> Kernel panic - not syncing: Fatal exception
> Pid: 12131, comm: insmod Tainted: G  D   2.6.32 #1
> Call Trace:
>  [] ? panic+0x7d/0x148
>  [] ? oops_end+0xe4/0x100
>  [] ? no_context+0xfb/0x260
>  [] ? __bad_area_nosemaphore+0x125/0x1e0
>  [] ? sysfs_ilookup_test+0x0/0x20
>  [] ? bad_area+0x4e/0x60
>  [] ? __do_page_fault+0x3c3/0x480
>  [] ? idr_get_empty_slot+0x110/0x2c0
>  [] ? ida_get_new_above+0xb0/0x210
>  [] ? sysfs_ilookup_test+0x0/0x20
>  [] ? do_page_fault+0x3e/0xa0
>  [] ? page_fault+0x25/0x30
>  [] ? misc_register+0x4c/0x170
>  [] ? misc_register+0x27/0x170
>  [] ? sce_new_smi+0x74/0x10c [ipmi_sce_logger]
>  [] ? ipmi_smi_watcher_register+0x121/0x240
> [ipmi_msghandler]
>  [] ? notifier_call_chain+0x55/0x80
>  [] ? ipmi_sce_init+0x0/0x3f [ipmi_sce_logger]
>  [] ? ipmi_sce_init+0x15/0x3f [ipmi_sce_logger]
>  [] ? do_one_initcall+0x3c/0x1d0
>  [] ? sys_init_module+0xdf/0x250
>  [] ? system_call_fastpath+0x16/0x1b
>
>  My smi de-register was not invoked so the next insmod caused mushroom
> cloud.
>
> Is this to be expected?
> Is there a way to fix this I don't know about?
>
> Dave
>
>
>
> --
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


---

Re: [Openipmi-developer] older versions of OpenIPMI append "0" to discrete sensor names

[Corey Minyard]

On 11/22/2013 09:18 AM, Aleksandrs Saveljevs wrote:
> Good morning,
>
> We noticed that OpenIPMI versions 2.0.16 through 2.0.18 append "0" to 
> discrete sensor names. Here is an example to illustrate that:
>
> $ ipmitool -U ... -P ... -I lan -H ... -L user sensor | grep 
> Processor.Status | cut -d'|' -f1,2,3
> Processor Status | 0x0| discrete
>
> We now launch different versions of ipmi_ui and view sensors for entity 
> 3.1 using "sensors 3.1" command:
>
> $ OpenIPMI-2.0.16-install/bin/ipmi_ui ...
> ...
> Sensors for entity
> 3.1:
>3.1.Processor~Status0 - Processor Status0
>
> $ OpenIPMI-2.0.19-install/bin/ipmi_ui ...
> ...
> Sensors for entity
> 3.1:
>3.1.Processor~Status - Processor Status
>
> It can be seen that in version 2.0.16 there is "0" appended to sensor 
> name, while version 2.0.19 does not have that.
>
> Since the "0" probably should not be there and since the newer version 
> fixes it, we assume the previous versions were a bit buggy. However, we 
> need to work around that bug in our software by increasing one of the 
> buffer sizes and we wish to know by how much we should increase it.
>
> Would increasing the maximum buffer size for sensor names by one byte 
> from 17 (16 for name plus terminating '\0') to 18 be enough?

That bug was there because there is an option in the IPMI SDRs (type 2)
to use the same SDR to represent multiple sensors, adding a number or an
alpha to the end of the name.  It was accidentally tacking this on to
the end of the sensor even if that option was not enabled.

However, your calculations on the maximum size of an IPMI sensor name
are incorrect.  Since you can use BCD and the field is 16 bytes max, you
can get up to 32 bytes in the ID string.  Adding the sensor sharing and
that's another three bytes (I believe 142 is the maximum number you can
get), so 35 bytes is the maximum, I believe.

-corey

>
> Aleksandrs
>
> --
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: remove deprecated IRQF_DISABLED

[Corey Minyard]

On 12/09/2013 03:31 AM, Michael Opdenacker wrote:
> Hi Corey,
>
> On 10/13/2013 09:45 PM, Corey Minyard wrote:
>> Thanks, it's in the queue.
>>
>> -corey
>>
>> On 10/12/2013 10:59 PM, Michael Opdenacker wrote:
>>> This patch proposes to remove the use of the IRQF_DISABLED flag
>>>
>>> It's a NOOP since 2.6.35 and it will be removed one day.
>>>
>>> Signed-off-by: Michael Opdenacker 
> Did you miss the latest merge window? I'm just asking to understand the
> process...

Yes, I did.  I was working with someone on another problem, and this is
the only thing I have queued, so I missed it.  I'll try to get it next
window.

-corey

>
> Thank you for your support.
>
> Cheers,
>
> Michael.
>


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 0/2] ipmi: fix timeout calculation when bmc is disconnected

[Corey Minyard]

Both look good, thank you.  I've queued them for the next window.

-corey

On 12/12/2013 08:36 PM, Xie XiuQi wrote:
> Hu Shiyuan report, when loading ipmi_si module while bmc is
> disconnected, we found the timeout is longer than 5 secs.
> Actually it takes about 3 mins and 20 secs (HZ=250).
>
> error message as below:
> Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
> Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
> [...]
> Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
> Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
> Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
> Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]
>
> Function wait_for_msg_done() use schedule_timeout_uninterruptible(1)
> to sleep 1 tick, so we should subtract jiffies_to_usecs(1) usecs
> instead of 100 usecs from timeout.
>
> For more clearly, I used USEC_PER_SEC instead of 100.
>
> Xie XiuQi (2):
>   ipmi: use USEC_PER_SEC instead of 100 for more meaningful
>   ipmi: fix timeout calculation when bmc is disconnected
>
>  drivers/char/ipmi/ipmi_bt_sm.c   | 8 
>  drivers/char/ipmi/ipmi_kcs_sm.c  | 4 ++--
>  drivers/char/ipmi/ipmi_si_intf.c | 2 +-
>  drivers/char/ipmi/ipmi_smic_sm.c | 2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)
>


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] IPMI Watchdog: response: Error c0 on cmd 22

[Corey Minyard]

On 12/17/2013 09:38 AM, Florian Pritz wrote:
> Hi,
>
> Just set up the watchdog on an Intel S1200RP board and I keep getting
> errors in dmesg, but "ipmitool mc watchdog get" gives the following
> output (present countdown is always >590 sec as I'd expect).
>
>> Watchdog Timer Use: SMS/OS (0x44)
>> Watchdog Timer Is:  Started/Running
>> Watchdog Timer Actions: Hard Reset (0x01)
>> Pre-timeout interval:   0 seconds
>> Timer Expiration Flags: 0x00
>> Initial Countdown:  600 sec
>> Present Countdown:  591 sec
> Log (every 10 seconds):
>> kernel: [25597.481186] IPMI Watchdog: response: Error c0 on cmd 22
>> systemd[1]: Failed to ping hardware watchdog: Invalid argument

That error means, from the spec: "Node Busy. Command could not be
processed because command processing
resources are temporarily unavailable."

I have no idea why it is returning that.

-corey

> What does c0 mean (can't find it in drivers/char/ipmi/)? I mean it
> obviously works (countdown gets reset), but I'd like to get rid of the
> message.
>
> I'm running linux 3.12.5 from Arch Linux with systemd which also handles
> the watchdog resets.
>
> PS: I'm not subscribed to the list, please make sure to CC me on replies.
>
>
>
> --
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [patch 5/6] Not sure for what exactly this could be

[Corey Minyard]

All the patches except one are correct and applied.  Thanks for the
fixes.  I need to get a formal release out soon, and this was a good
addition.

The following patch is incorrect.  It was caught by some automatic
printf checker, but the call here doesn't exactly match printf
semantics.  So please remove this one.

Thanks again,

-corey

diff -wruN -x '*~' -x '*.o' -x '*.a' -x '*.so' -x '*.so.[0-9]' -x 
autom4te.cache -x .deps -x .libs ../orig-OpenIPMI-2.0.20-rc3/swig/OpenIPMI.i 
./swig/OpenIPMI.i
--- ../orig-OpenIPMI-2.0.20-rc3/swig/OpenIPMI.i 2013-08-28 17:02:23.0 
+0200
+++ ./swig/OpenIPMI.i   2013-10-04 09:50:14.951385925 +0200
@@ -2666,7 +2666,7 @@
 int rv = 0;
 
 conn_ref = swig_make_ref(conn, ipmi_sol_conn_t);
-swig_call_cb_rv('i', &rv, cb, "sol_data_received", "%p%*b",
+swig_call_cb_rv('i', &rv, cb, "sol_data_received", "%p%*s",
&conn_ref, count, buf);
 swig_free_ref_check(conn_ref, ipmi_sol_conn_t);
 return rv;


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Openipmi for arm

[Corey Minyard]

The library already runs on ARM Linux and is tested.  The driver should
work, too, though I don't know of any current ARM platforms that support
and IPMI interface.  What exactly are you trying to do?

-corey

On 01/14/2014 08:08 PM, Frank W. Miller wrote:
>  
> Greetings,
>  
> I'm considering porting this code to a new ARM based server platform. 
> I would appreciate and comments or suggestions on such a task.
>  
> Thanks,
> FM
>  
> Frank W. Miller
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] Openipmi for arm

[Corey Minyard]

On 01/14/2014 11:06 PM, Frank W. Miller wrote:
>
> We have a customer that is asking for IPMI and this software looks like it
> can help us meet that requirement.  The system is described at
> www.cornfedservers.com

It sounds like they want IPMI manageability.  Parts of the library can
provide help for this, but the systems have to be built with a separate
management processor to be IPMI compliant.  Unless the hardware has it,
there's not much point in pursuing IPMI.

If they do have a separate management processor, then parts of the
openipmi library can help create a management controller on that processor.

-corey

>
> I'll try building it in.
>
> Thanks,
> FM
>  
>
> -----Original Message-
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard
> Sent: Tuesday, January 14, 2014 8:37 PM
> To: Frank W. Miller; openipmi-developer@lists.sourceforge.net
> Subject: Re: [Openipmi-developer] Openipmi for arm
>
> The library already runs on ARM Linux and is tested.  The driver should
> work, too, though I don't know of any current ARM platforms that support and
> IPMI interface.  What exactly are you trying to do?
>
> -corey
>
> On 01/14/2014 08:08 PM, Frank W. Miller wrote:
>>  
>> Greetings,
>>  
>> I'm considering porting this code to a new ARM based server platform. 
>> I would appreciate and comments or suggestions on such a task.
>>  
>> Thanks,
>> FM
>>  
>> Frank W. Miller
>>
>>
>> --
>>  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
>> Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.
>> clktrk
>>
>>
>> ___
>> Openipmi-developer mailing list
>> Openipmi-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>
>
> --
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> ___
> Openipmi-developer mailing list
> Openipmi-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

[Openipmi-developer] Name change on the new OpenIPMI package

[Corey Minyard]

I didn't realize it, but the rework to modernize the autoconf file
caused the tarball and directory names to be downcased from OpenIPMI to
openipmi.  I've fixed the issue and uploaded a new version of
OpenIPMI-2.0.20 that is correctly named.  Sorry about that.  I didn't
even notice when uploading it.

-corey

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: Add missing rv in ipmi_parisc_probe()

[Corey Minyard]

On 01/28/2014 01:12 PM, Geert Uytterhoeven wrote:
> drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_parisc_probe':
> drivers/char/ipmi/ipmi_si_intf.c:2752:2: error: 'rv' undeclared (first use in 
> this function)
> drivers/char/ipmi/ipmi_si_intf.c:2752:2: note: each undeclared identifier is 
> reported only once for each function it appears in
>
> Introduced by commit d02b3709ff8efebfca0612d0ac2a6e31a91c13f4 ("ipmi:
> Cleanup error return")
>
> Signed-off-by: Geert Uytterhoeven 

Dang it.  Yes, you are right, of course.

Acked-by: Corey Minyard 
> ---
> http://kisskb.ellerman.id.au/kisskb/buildresult/10537567/
>
>  drivers/char/ipmi/ipmi_si_intf.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c 
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 671c3852d359..03f41896d090 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2724,6 +2724,7 @@ static struct platform_driver ipmi_driver = {
>  static int ipmi_parisc_probe(struct parisc_device *dev)
>  {
>   struct smi_info *info;
> + int rv;
>  
>   info = smi_info_alloc();
>  


--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH] ipmi: fix BT reset for a while when cmd timeout

[Corey Minyard]

I don't really understand the error that is happening.  I see that it
continues to time out, but I don't know why.  If you can get in to this
situation here, it makes me worried that there is some other issue. 
issuing the warm reset, even if the command is not supported, should be
harmless.  Maybe the warm reset actually happens and it takes longer
than 5 seconds?

The following patch is certainly not the right fix.  I would actually
prefer to just remove the reset operation from the driver, but I'd
really like to fix the fundamental issue.  To me this looks like a bug
in the BMC.

I'm copying Rocky Craig, who wrote this state machine.

-corey

On 02/11/2014 04:26 AM, Xie XiuQi wrote:
> I fould a problem: when a cmd timeout and just
> in that time bt->seq < 2, system will alway keep
> retrying and we can't send any cmd to bmc.
>
> the error message is like this:
> [  530.908621] IPMI BT: timeout in RD_WAIT [ ] 1 retries left
> [  582.661329] IPMI BT: timeout in RD_WAIT [ ]
> [  582.661334] failed 2 retries, sending error response
> [  582.661337] IPMI: BT reset (takes 5 secs)
> [  693.335307] IPMI BT: timeout in RD_WAIT [ ]
> [  693.335312] failed 2 retries, sending error response
> [  693.335315] IPMI: BT reset (takes 5 secs)
> [  804.825161] IPMI BT: timeout in RD_WAIT [ ]
> [  804.825166] failed 2 retries, sending error response
> [  804.825169] IPMI: BT reset (takes 5 secs)
> ...
>
> When BT reset, a cmd "warm reset" will be sent to bmc, but this cmd
> is Optional in spec(refer to ipmi-interface-spec-v2). Some machines
> don't support this cmd.
>
> So, bt->init is introduced. Only during insmod, we do BT reset when
> response timeout to avoid system crash.
>
> Reported-by: Hu Shiyuan 
> Signed-off-by: Xie XiuQi 
> Cc: sta...@vger.kernel.org# 3.4+
> ---
>  drivers/char/ipmi/ipmi_bt_sm.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
> index a22a7a5..b4a7b2a 100644
> --- a/drivers/char/ipmi/ipmi_bt_sm.c
> +++ b/drivers/char/ipmi/ipmi_bt_sm.c
> @@ -107,6 +107,7 @@ struct si_sm_data {
>   int BT_CAP_outreqs;
>   longBT_CAP_req2rsp;
>   int BT_CAP_retries; /* Recommended retries */
> + int init;
>  };
>
>  #define BT_CLR_WR_PTR0x01/* See IPMI 1.5 table 11.6.4 */
> @@ -438,8 +439,8 @@ static enum si_sm_result error_recovery(struct si_sm_data 
> *bt,
>   if (!bt->nonzero_status)
>   printk(KERN_ERR "IPMI BT: stuck, try power cycle\n");
>
> - /* this is most likely during insmod */
> - else if (bt->seq <= (unsigned char)(bt->BT_CAP_retries & 0xFF)) {
> + /* only during insmod */
> + else if (!bt->init) {
>   printk(KERN_WARNING "IPMI: BT reset (takes 5 secs)\n");
>   bt->state = BT_STATE_RESET1;
>   return SI_SM_CALL_WITHOUT_DELAY;
> @@ -589,6 +590,10 @@ static enum si_sm_result bt_event(struct si_sm_data *bt, 
> long time)
>   BT_STATE_CHANGE(BT_STATE_READ_WAIT,
>   SI_SM_CALL_WITHOUT_DELAY);
>   bt->state = bt->complete;
> +
> + if (!bt->init && bt->seq)
> + bt->init = 1;
> +
>   return bt->state == BT_STATE_IDLE ? /* where to next? */
>   SI_SM_TRANSACTION_COMPLETE :/* normal */
>   SI_SM_CALL_WITHOUT_DELAY;   /* Startup magic */


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 1/3] ipmi: Turn off default probing of interfaces

[Corey Minyard]

On 02/24/2014 10:53 AM, Dmitry Torokhov wrote:
> Hi Corey,
>
> On Sun, Feb 23, 2014 at 08:23:34PM -0600, miny...@acm.org wrote:
> Would not
>
> static bool  si_trydefaults = 
> IS_ENABLED(CONFIG_IPMI_SI_PROBE_DEFAULTS);
>
> work better here?
>
> Thanks.
>
Certainly.  I will update it.  Thanks,

-corey

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Re: [Openipmi-developer] [PATCH 2/3] ipmi: Turn off all activity on an idle ipmi interface

[Corey Minyard]

On 02/24/2014 10:57 AM, Dmitry Torokhov wrote:
> On Sun, Feb 23, 2014 at 08:23:35PM -0600, miny...@acm.org wrote:
>> @@ -1194,7 +1223,17 @@ int ipmi_set_gets_events(ipmi_user_t user, int val)
>>  INIT_LIST_HEAD(&msgs);
>>  
>>  spin_lock_irqsave(&intf->events_lock, flags);
>> -user->gets_events = val;
>> +if (user->gets_events == !!val)
>> +goto out;
>> +
>> +user->gets_events = !!val;
> Why not have val declared as bool and let compiler convert as needed?
>
> Thanks.
>
Because I've been programming in C since long before there was a bool
type, and I need to change the way I think.  Fixed, thanks.

-core

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer