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> <mailto:yicheng....@hp.com> To: Corey Minyard <miny...@acm.org> <mailto:miny...@acm.org> , "Mingarelli, Thomas" <thomas.mingare...@hp.com> <mailto: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> <mailto:yicheng....@hp.com> Acked-by: Tom Mingarelli<thomas.mingare...@hp.com> <mailto: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> <mailto:yicheng....@hp.com> > Acked-by: Tom Mingarelli<thomas.mingare...@hp.com> <mailto: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
