linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Venture <venture@google.com>
To: Corey Minyard <minyard@acm.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	openipmi-developer@lists.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH v2] ipmi: looped device detection
Date: Tue, 18 Sep 2018 11:42:40 -0700	[thread overview]
Message-ID: <CAO=notwkMAe_9=32D+ycPwiZ=c_un7sQ+Le9PW_oDiVeBp25jg@mail.gmail.com> (raw)
In-Reply-To: <CAO=notzHoqsjuSdEZby0mr3KgtoxtYjdr_X0nM_2zBu0NcOOAA@mail.gmail.com>

On Wed, Sep 12, 2018 at 3:54 PM Patrick Venture <venture@google.com> wrote:
>
> On Wed, Sep 12, 2018 at 3:10 PM Corey Minyard <minyard@acm.org> wrote:
> >
> > On 09/11/2018 05:56 PM, Patrick Venture wrote:
> > > Try to get the device ID repeatedly during initialization before giving up.
> > > The BMC isn't always responsive, and this allows it to be slightly flaky
> > > during early boot.
> > >
> > > Tested: Installed on a system with the BMC software disabled
> > > such that it was non-responsive.  The driver correctly detected this
> > > and gave up as expected.  Then I re-enabled the BMC software unloaded
> > > and reloaded the driver and it was detected properly.
> >
> > The patch looks fine, but I wonder if this is something that is really
> > valuable.
> > I have wondered about this before.
> >
> > The question is: If the BMC is unavailable, what are the chances of it
> > becoming
> > available by the time you do 5 attempts?  I would guess that is a pretty
> > small
> > chance, which is why I haven't done this already.

Friendly ping.  I'd like to get a sense of whether you're likely to
accept this.  If not, it's fine, will close out patch in current
downstream rebase.

Thanks

>
> This patch was actually critical for us to provide a reliable IPMI
> interface.  The version of OpenBMC or the state of the BMC at the
> point the kernel was loading was flaky, so following the example in
> the BIOS source, we just re-try a few times.  We also can hold boot X
> seconds until it's responding, but, this avoided some issues inherent
> with that.
>
> >
> > You could have something that re-tested periodically, but there are so many
> > systems with IPMI specified in ACPI or SMBIOS that is wrong, and it would
> > try forever.  Also not really a good thing.
>
> If we did a periodic check, it could check X times, but I felt going
> for a simple solution was ideal -- and this idea was proved out on a
> few platforms.  We have other drivers that are loaded by the kernel
> (not at run-time) and they depend on IPMI, and without this patch they
> would then have a non-trivial probability of failure.
>
> >
> > So I've left it to reload the driver or use the hotmod interface.
> >
> > -corey
> >
> > > Signed-off-by: Patrick Venture <venture@google.com>
> > > ---
> > > v2:
> > >   - removed extra variable that was set but not used.
> > > ---
> > >   drivers/char/ipmi/ipmi_si_intf.c | 23 ++++++++++++++++++++++-
> > >   1 file changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
> > > index 90ec010bffbd..5fed96897fe8 100644
> > > --- a/drivers/char/ipmi/ipmi_si_intf.c
> > > +++ b/drivers/char/ipmi/ipmi_si_intf.c
> > > @@ -1918,11 +1918,13 @@ int ipmi_si_add_smi(struct si_sm_io *io)
> > >    * held, primarily to keep smi_num consistent, we only one to do these
> > >    * one at a time.
> > >    */
> > > +#define GET_DEVICE_ID_ATTEMPTS       5
> > >   static int try_smi_init(struct smi_info *new_smi)
> > >   {
> > >       int rv = 0;
> > >       int i;
> > >       char *init_name = NULL;
> > > +     unsigned long sleep_rm;
> > >
> > >       pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, slave address 0x%x, irq %d\n",
> > >               ipmi_addr_src_to_str(new_smi->io.addr_source),
> > > @@ -2003,7 +2005,26 @@ static int try_smi_init(struct smi_info *new_smi)
> > >        * Attempt a get device id command.  If it fails, we probably
> > >        * don't have a BMC here.
> > >        */
> > > -     rv = try_get_dev_id(new_smi);
> > > +     for (i = 0; i < GET_DEVICE_ID_ATTEMPTS; i++) {
> > > +             pr_info(PFX "Attempting to read BMC device ID\n");
> > > +             rv = try_get_dev_id(new_smi);
> > > +             /* If it succeeded, stop trying */
> > > +             if (!rv)
> > > +                     break;
> > > +
> > > +             /* Sleep for ~0.25s before trying again instead of hammering
> > > +              * the BMC.
> > > +              */
> > > +             sleep_rm = msleep_interruptible(250);
> > > +             if (sleep_rm != 0) {
> > > +                     pr_info(PFX "Find BMC interrupted\n");
> > > +                     rv = -EINTR;
> > > +                     goto out_err;
> > > +             }
> > > +     }
> > > +
> > > +     /* If we exited the loop above and rv is non-zero we ran out of tries.
> > > +      */
> > >       if (rv) {
> > >               if (new_smi->io.addr_source)
> > >                       dev_err(new_smi->io.dev,
> >
> >

  reply	other threads:[~2018-09-18 18:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11 22:56 [PATCH v2] ipmi: looped device detection Patrick Venture
2018-09-12 22:09 ` Corey Minyard
2018-09-12 22:54   ` Patrick Venture
2018-09-18 18:42     ` Patrick Venture [this message]
2018-09-18 21:37       ` Corey Minyard
2018-09-19 19:56         ` Patrick Venture
2018-09-19 20:20           ` Corey Minyard
2018-09-20 18:08             ` Patrick Venture

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='CAO=notwkMAe_9=32D+ycPwiZ=c_un7sQ+Le9PW_oDiVeBp25jg@mail.gmail.com' \
    --to=venture@google.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).