Hi Corey,
The patch seems to work for us too, thanks. Unpatched version failed the
first time usually after only few runs of 'busybox watch ipmitool sdr',
with the patched version it has survived fine for about half an hour now.
-Mika
From: "Andy Cress" <andy.cr...@us.kontron.com>
To: "Corey Minyard" <miny...@acm.org>, <yicheng....@hp.com>,
"Audet, Jean-Michel" <jean-michel.au...@ca.kontron.com>,
<openipmi-develo...@lists.sourceforge.net>,
<ipmitool-devel@lists.sourceforge.net>,
<jozef.sudol...@elbiahosting.sk>,
<mika.lansiri...@stonesoft.com>, <m...@redhat.com>
Date: 22.02.2011 19:39
Subject: RE: [Ipmitool-devel] [ipmi_si_intf PATCH] based on 2.6.36
kernel
Corey,
We have seen these incorrect response messages on RHEL6 (ipmi v39.2) with
an Intel S5520UR baseboard in less than 10 minutes with an activity script,
and with the patch applied, it did not show the problem in an overnight
test.
Looks good to me.
Andy
From: Corey Minyard [mailto:miny...@acm.org]
Sent: Tuesday, February 22, 2011 12:18 PM
To: yicheng....@hp.com; Audet, Jean-Michel;
openipmi-develo...@lists.sourceforge.net;
ipmitool-devel@lists.sourceforge.net; jozef.sudol...@elbiahosting.sk;
mika.lansiri...@stonesoft.com; m...@redhat.com
Subject: [Ipmitool-devel] Fwd: RE: [ipmi_si_intf PATCH] based on
2.6.36kernel
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 +0000
From: Doe, YiCheng <yicheng....@hp.com>
To: Corey Minyard <miny...@acm.org>, "Mingarelli, Thomas"
<thomas.mingare...@hp.com>
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<yicheng....@hp.com>
Acked-by: Tom Mingarelli<thomas.mingare...@hp.com>
---
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.000000000 -0500
+++ linux-2.6.36.2p/drivers/char/ipmi/ipmi_si_intf.c 2011-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<yicheng....@hp.com>
> Acked-by: Tom Mingarelli<thomas.mingare...@hp.com>
>
> ---
>
> 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.000000000 -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/splunk-dev2dev
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
