Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933239AbbHZU1X (ORCPT ); Wed, 26 Aug 2015 16:27:23 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:32816 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751831AbbHZU1V (ORCPT ); Wed, 26 Aug 2015 16:27:21 -0400 Message-ID: <55DE2127.3010402@acm.org> Date: Wed, 26 Aug 2015 15:27:19 -0500 From: Corey Minyard Reply-To: minyard@acm.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= CC: "openipmi-developer@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE References: <20150727055516.4759.34462.stgit@softrs> <20150727055516.4759.65106.stgit@softrs> <55CAC849.70902@acm.org> <04EAB7311EE43145B2D3536183D1A84454938089@GSjpTKYDCembx31.service.hitachi.net> <55D8B543.4000805@acm.org> <04EAB7311EE43145B2D3536183D1A8445493D025@GSjpTKYDCembx31.service.hitachi.net> <55DB3F8E.5030100@acm.org> <04EAB7311EE43145B2D3536183D1A8445495009D@GSjpTKYDCembx31.service.hitachi.net> In-Reply-To: <04EAB7311EE43145B2D3536183D1A8445495009D@GSjpTKYDCembx31.service.hitachi.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2692 Lines: 59 On 08/24/2015 10:53 PM, 河合英宏 / KAWAI,HIDEHIRO wrote: >> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard >> >> On 08/23/2015 08:52 PM, 河合英宏 / KAWAI,HIDEHIRO wrote: >>>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard >>>> >>>> On 08/17/2015 09:54 PM, 河合英宏 / KAWAI,HIDEHIRO wrote: >>>>>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard >>>>>> >>>>>> This patch will break ATN handling on the interfaces. So we can't do this. >>>>> I understand. So how about doing like this: >>>>> >>>>> /* All states wait for ibf, so just do it here. */ >>>>> - if (!check_ibf(kcs, status, time)) >>>>> + if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time)) >>>>> return SI_SM_CALL_WITH_DELAY; >>>>> >>>>> I think it is not necessary to wait IBF when the state is IDLE. >>>>> In this way, we can also handle the ATN case. >>>> I think it would be more reliable to go up a level and add a timeout. >>> It may be so, but we should address this issue separately (at least >>> I think above solution reasonably solves the issue). >>> >>> This issue happens after all queued messages are processed or dropped >>> by timeout. There is no current message. So what should we set >>> a timeout against? We can add a timeout into my new flush_messages(), >>> but that is meaningful only in panic context. That doesn't help >>> in normal context; we would perform a busy loop of smi_event_handler() >>> and schedule() in ipmi_thread(). >> I'm a little confused here. Is the problem that the ATN bit is stuck >> high? If so, it's going to be really hard to work around this without >> breaking ATN handling. > Sorry for my insufficient explanation. I assume the case where > IBF bit is always 1. I don't know what happens when > BMC hangs up, but I guess IBF stays in 1 because my server's > BMC behaves as such while rebooting. > Ok, your patch above makes sense, then. IBF is irrelevant when in idle state, so ignore it then, and then in your case it will return KCS_IDLE and cause that operation to complete. I'm ok with the patch you posted above, I think it will work correctly and solve the problem. I would like a detailed comment, though, so people (forgetful people like me :) can figure out why it is there. I'd also like to save this one until 4.4 to give it some time in linux-next for people to find issues. Thanks, -corey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/