All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.