public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: <Srinivas_G_Gowda@Dell.com>
To: <minyard@acm.org>
Cc: <tcminyard@gmail.com>, <linux-kernel@vger.kernel.org>,
	<openipmi@mvista.com>
Subject: Re: [PATCH 1/1] ipmi: setting mod_timer for read_event_msg buffer cmd
Date: Mon, 2 Dec 2013 20:19:42 +0530	[thread overview]
Message-ID: <529C9C99.2010108@dell.com> (raw)
In-Reply-To: <52992EFA.4000903@acm.org>


Thanks for the patch Corey. 
I am afraid that the system does not have interrupts enabled. It uses polling mode. 

When the error is seen, I know for a fact that in function ipmi_thread() smi_result is SI_SM_CALL_WITH_DELAY, 
I have some logs where in busy_wait always reads as 1. Not sure if it was ever set to 0. (ill check this again). 
Ill anyway run the test using the patch that you have shared. 

b/w would it harm if we were to do to something like this ?  

Signed-off-by: Srinivas Gowda <srinivas_g_gowda@dell.com>
---
 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 15e4a60..e23484f 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1008,6 +1008,7 @@ static int ipmi_thread(void *data)
 		spin_unlock_irqrestore(&(smi_info->si_lock), flags);
 		busy_wait = ipmi_thread_busy_wait(smi_result, smi_info,
 						  &busy_until);
+		ipmi_start_timer_if_necessary(smi_info);
 		if (smi_result == SI_SM_CALL_WITHOUT_DELAY)
 			; /* do nothing */
 		else if (smi_result == SI_SM_CALL_WITH_DELAY && busy_wait)
-- 
1.8.1.2
  

Thanks,
G



On 11/30/2013 05:49 AM, Corey Minyard wrote:

> On 11/27/2013 04:34 AM, Srinivas_G_Gowda@Dell.com wrote:
>>
>> *Dell - Internal Use - Confidential *
>>
>> I hit a bug during one of our stress tests, Here is the issue that I
>> am looking at.
>>
>> We have IPMI_READ_EVENT_MSG_BUFFER_CMD getting invoked from
>> smi_event_handler.
>>
>> In case we hit error scenario, say "OBF not ready in time" we do not
>> have smi_timeout driving the interface.
>>
>> Seems like the timer is not armed when we invoke
>> IPMI_READ_EVENT_MSG_BUFFER_CMD from smi_event_handler.
>>
>> For the proposed patch I checked the return value of mod_timer just
>> before smi_info->handlers->start_transaction, that returns 0 !!!
>>
>> gWithout smi_timeout handler getting called periodically, if the BMC
>> fails to set OBF flag during the msg transaction of
>> IPMI_READ_EVENT_MSG_BUFFER_CMD,
>>
>> the driver just keeps looping until the flag is set. Ideally we would
>> want BMC to set the flag, but in case it doesn’t we do not want the
>> driver to loop indefinitely rather hit KCS_ERROR states.
>>
>> To summarize, we do not have timer set to invoke smi_timeout() when we
>> call IPMI_READ_EVENT_MSG_BUFFER_CMD from smi_event_handler.
>>
>> Do you feel there is a better way to fix it or a bug elsewhere…!
>>
> 
> Ok, I think I know what is happening, and I think I have a fix. I'm
> betting that you have interrupts on this, and
> I found a situation where if an interrupt came in at a certain time, it
> wouldn't start the timer. The attached patch should fix the problem.
> 
> Can you try this out?
> 
> Thanks for the detailed description.
> 
> -corey




  reply	other threads:[~2013-12-02 14:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-25  9:51 [PATCH 1/1] ipmi: setting mod_timer for read_event_msg buffer cmd Srinivas_G_Gowda
2013-11-26 17:26 ` Corey Minyard
     [not found]   ` <75F7F7632819D94BA80703D8B1F10B6D29CEE95A1D@BLRX7MCDC201.AMER.DELL.COM>
2013-11-30  0:19     ` Corey Minyard
2013-12-02 14:49       ` Srinivas_G_Gowda [this message]
2013-12-02 21:03         ` Corey Minyard
2013-12-03  6:18           ` Srinivas_G_Gowda
2013-12-03 17:10             ` Corey Minyard
2013-12-04 11:58               ` Srinivas_G_Gowda
2013-12-05 12:40                 ` Srinivas_G_Gowda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529C9C99.2010108@dell.com \
    --to=srinivas_g_gowda@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=openipmi@mvista.com \
    --cc=tcminyard@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox