> > No, I did not see final else in ipmi_thread ever getting hit. > > I am looking at ipmi_thread_busy_wait(), > by default the below condition never gets set unitl I explicetly set > "kipmid_max_busy_us" to some value. > if (smi_info->intf_num < num_max_busy_us) > > This means by default "max_busy_us" is always 0. Hence Ill basically end up > only doing this > if (max_busy_us == 0 || smi_result != SI_SM_CALL_WITH_DELAY) > ipmi_si_set_not_busy(busy_until); > > That probably explains why I never hit the else condition in ipmi_thread. > > I see ipmi_start_timer_if_necessary() getting called from ipmi_thread() after > setting "kipmid_max_busy_us" > Ill set "kipmid_max_busy_us=300" and run the stress. I am hoping that we will > not see the issue in this case. >
I don't see the issue after this change. (I am going to try again just to be sure) I am trying to figure out how to hit ipmi_start_timer_if_necessary() in default mode...! Thanks, G > > Thanks, > G > > > >> Thanks, >> >> -corey >> >>> >>> >>> Thanks, >>> G >>> >>> -----Original Message----- >>> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard >>> Sent: Tuesday, December 03, 2013 2:34 AM >>> To: Gowda, Srinivas G >>> Cc: tcminy...@gmail.com; linux-kernel@vger.kernel.org; openi...@mvista.com >>> Subject: Re: [PATCH 1/1] ipmi: setting mod_timer for read_event_msg buffer >>> cmd On 12/02/2013 08:49 AM, srinivas_g_go...@dell.com wrote: >>>> 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 ? >>> Unfortunately, that would start the timer unnecessarily. You don't want to >>> start timers unnecessarily in the kernel or the power management police >>> will come after you. >>> The patch I sent did have this call in the non-idle portion of the kernel >>> thread and that should have done the same thing. Plus, if you are using >>> the kernel thread, it's going to run periodically and should kick things >>> off again if they get stuck. I'm suspicious now that something else is >>> going on. >>> -corey >>>> Signed-off-by: Srinivas Gowda <srinivas_g_go...@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) >> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
