public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ipmi: Run a dummy command before submitting a new command
Date: Tue, 27 Jul 2010 12:07:11 -0500	[thread overview]
Message-ID: <4C4F123F.3010700@mvista.com> (raw)
In-Reply-To: <1280246493-964-1-git-send-email-mjg@redhat.com>

I don't think this is the right way to handle the problem.  Though it's 
not going to break anything, this change is just a hack.  We need to 
figure out why these machine exhibit this behavior.  If it's a bug in 
the driver, then we need to fix the driver.  If it's a bug in the HP 
firmware, then we need to document it well as such, get HP to fix their 
firmware, and possibly tie it into the xaction handler that's already in 
start_next_msg.

The only interaction with the device that this change should cause is 
one read from the status register, since the device should be idle at 
this point.  If that's the case, and it's not a driver bug, you can try 
adding an xaction that calls smi_info->handlers->event(smi_info->si_sm, 0).

There are debugging flags in the state machines that might help debug 
this, too.

-corey

On 07/27/2010 11:01 AM, Matthew Garrett wrote:
> Newer firmware revisions on HP's ILO3 (1.05 and later) generate state
> machine errors with the current IPMI code. Running through the IPMI
> timeout handler once before submitting the command avoids this.
>
> Signed-off-by: Matthew Garrett<mjg@redhat.com>
> Cc: Corey Minyard<cminyard@mvista.com>
> ---
>   drivers/char/ipmi/ipmi_si_intf.c |    2 ++
>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
> index e39a744..3f06199 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -317,6 +317,7 @@ static int unload_when_empty = 1;
>   static int add_smi(struct smi_info *smi);
>   static int try_smi_init(struct smi_info *smi);
>   static void cleanup_one_si(struct smi_info *to_clean);
> +static void smi_timeout(unsigned long data);
>
>   static ATOMIC_NOTIFIER_HEAD(xaction_notifier_list);
>   static int register_xaction_notifier(struct notifier_block *nb)
> @@ -897,6 +898,7 @@ static void sender(void                *send_info,
>   #endif
>
>   	mod_timer(&smi_info->si_timer, jiffies + SI_TIMEOUT_JIFFIES);
> +	smi_timeout((unsigned long)smi_info);
>
>   	if (smi_info->thread)
>   		wake_up_process(smi_info->thread);
>    


  reply	other threads:[~2010-07-27 17:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 16:01 [PATCH] ipmi: Run a dummy command before submitting a new command Matthew Garrett
2010-07-27 17:07 ` Corey Minyard [this message]
2010-07-27 17:21   ` Matthew Garrett
2010-10-26 17:45     ` Matthew Garrett

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=4C4F123F.3010700@mvista.com \
    --to=cminyard@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.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