public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Xie XiuQi <xiexiuqi@huawei.com>
Cc: Hushiyuan <hushiyuan@huawei.com>,
	openipmi-developer@lists.sourceforge.net,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rocky Craig <rocky.craig@hp.com>
Subject: Re: [Openipmi-developer] [PATCH] ipmi: fix BT reset for a while when cmd timeout
Date: Sat, 15 Feb 2014 22:44:11 -0600	[thread overview]
Message-ID: <5300421B.1020901@acm.org> (raw)
In-Reply-To: <52F9FAC4.4040105@huawei.com>

I don't really understand the error that is happening.  I see that it
continues to time out, but I don't know why.  If you can get in to this
situation here, it makes me worried that there is some other issue. 
issuing the warm reset, even if the command is not supported, should be
harmless.  Maybe the warm reset actually happens and it takes longer
than 5 seconds?

The following patch is certainly not the right fix.  I would actually
prefer to just remove the reset operation from the driver, but I'd
really like to fix the fundamental issue.  To me this looks like a bug
in the BMC.

I'm copying Rocky Craig, who wrote this state machine.

-corey

On 02/11/2014 04:26 AM, Xie XiuQi wrote:
> I fould a problem: when a cmd timeout and just
> in that time bt->seq < 2, system will alway keep
> retrying and we can't send any cmd to bmc.
>
> the error message is like this:
> [  530.908621] IPMI BT: timeout in RD_WAIT [ ] 1 retries left
> [  582.661329] IPMI BT: timeout in RD_WAIT [ ]
> [  582.661334] failed 2 retries, sending error response
> [  582.661337] IPMI: BT reset (takes 5 secs)
> [  693.335307] IPMI BT: timeout in RD_WAIT [ ]
> [  693.335312] failed 2 retries, sending error response
> [  693.335315] IPMI: BT reset (takes 5 secs)
> [  804.825161] IPMI BT: timeout in RD_WAIT [ ]
> [  804.825166] failed 2 retries, sending error response
> [  804.825169] IPMI: BT reset (takes 5 secs)
> ...
>
> When BT reset, a cmd "warm reset" will be sent to bmc, but this cmd
> is Optional in spec(refer to ipmi-interface-spec-v2). Some machines
> don't support this cmd.
>
> So, bt->init is introduced. Only during insmod, we do BT reset when
> response timeout to avoid system crash.
>
> Reported-by: Hu Shiyuan <hushiyuan@huawei.com>
> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
> Cc: stable@vger.kernel.org	# 3.4+
> ---
>  drivers/char/ipmi/ipmi_bt_sm.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_bt_sm.c b/drivers/char/ipmi/ipmi_bt_sm.c
> index a22a7a5..b4a7b2a 100644
> --- a/drivers/char/ipmi/ipmi_bt_sm.c
> +++ b/drivers/char/ipmi/ipmi_bt_sm.c
> @@ -107,6 +107,7 @@ struct si_sm_data {
>  	int		BT_CAP_outreqs;
>  	long		BT_CAP_req2rsp;
>  	int		BT_CAP_retries;	/* Recommended retries */
> +	int		init;
>  };
>
>  #define BT_CLR_WR_PTR	0x01	/* See IPMI 1.5 table 11.6.4 */
> @@ -438,8 +439,8 @@ static enum si_sm_result error_recovery(struct si_sm_data *bt,
>  	if (!bt->nonzero_status)
>  		printk(KERN_ERR "IPMI BT: stuck, try power cycle\n");
>
> -	/* this is most likely during insmod */
> -	else if (bt->seq <= (unsigned char)(bt->BT_CAP_retries & 0xFF)) {
> +	/* only during insmod */
> +	else if (!bt->init) {
>  		printk(KERN_WARNING "IPMI: BT reset (takes 5 secs)\n");
>  		bt->state = BT_STATE_RESET1;
>  		return SI_SM_CALL_WITHOUT_DELAY;
> @@ -589,6 +590,10 @@ static enum si_sm_result bt_event(struct si_sm_data *bt, long time)
>  			BT_STATE_CHANGE(BT_STATE_READ_WAIT,
>  					SI_SM_CALL_WITHOUT_DELAY);
>  		bt->state = bt->complete;
> +
> +		if (!bt->init && bt->seq)
> +			bt->init = 1;
> +
>  		return bt->state == BT_STATE_IDLE ?	/* where to next? */
>  			SI_SM_TRANSACTION_COMPLETE :	/* normal */
>  			SI_SM_CALL_WITHOUT_DELAY;	/* Startup magic */


      reply	other threads:[~2014-02-16  4:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 10:26 [PATCH] ipmi: fix BT reset for a while when cmd timeout Xie XiuQi
2014-02-16  4:44 ` Corey Minyard [this message]

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=5300421B.1020901@acm.org \
    --to=minyard@acm.org \
    --cc=hushiyuan@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=rocky.craig@hp.com \
    --cc=xiexiuqi@huawei.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