linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Jerry.Hoemann@hpe.com, Ivan Mironov <mironov.ivan@gmail.com>
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
	Wim Van Sebroeck <wim@linux-watchdog.org>
Subject: Re: [RFC PATCH 1/4] watchdog: hpwdt: Don't disable watchdog on NMI
Date: Thu, 7 Feb 2019 20:17:29 -0800	[thread overview]
Message-ID: <4f7de732-31cf-a220-f1eb-3d8182cf9c72@roeck-us.net> (raw)
In-Reply-To: <20190208012658.GF28168@anatevka>

On 2/7/19 5:26 PM, Jerry Hoemann wrote:
> On Sat, Feb 02, 2019 at 09:55:29AM +0500, Ivan Mironov wrote:
>> On Tue, 2019-01-15 at 19:27 -0700, Jerry Hoemann wrote:
>>> On Mon, Jan 14, 2019 at 07:36:14AM +0500, Ivan Mironov wrote:
>>
>> Somehow I missed the whole pretimout thing when reading about the
>> watchdog API. Thanks for clarification, now code makes much more sense
>> =).
>>
>> Still, I do not really understand the point of enabling of kdump
>> support in hpwdt driver by default while kdump is not enabled by
>> default.
> 
> Kdump is enabled by default by our Distro partners.
> 
> HPE works with distro partners to deliver a validated system which we support.
> 
> The ability to generate crash dumps is one of the means we use to
> support our customers.  Even if kdump isn't configured, panic will
> at least print stack trace to indicate system activity.
> 
> 
>>
>> Also, existing code may call hpwdt_stop() (and thus break watchdog)
>> even if pretimout is disabled.
>>
>> Also, "panic=N" option is not providing a way to *not* panic on NMI
>> unrelated with iLO. This could be circumvented by blacklisting the
>> hpwdt module entirely, but normal watchdog functionality would be lost
>> then.
> 
> panic=N provides for reset upon receipt of NMI if user wants timeout
> to reset system but not a crash dump.
> 
> The panic is for error containment.  On the legacy systems within
> the context of hpwdt_pretimeout we cannot determine if the error
> is recoverable or not.  So, we have little choice but to panic.
> 
> 
>>
>> It is possible to rebuild kernel without HPWDT_NMI_DECODING (which is
>> enabled in Fedora, for example). But it is nearly impossible to come to
>> this solution without examining the source code, because description of
>> this option does not mention that it is really about pretimout support
>> and panics and not about something else...
> 
> The name is not the best given its current use, but I'm not sure a
> name change would be allowed.
> 

I would be open to accepting an improved help text of this configuration
option. I am not going to entertain (or accept) a name change.
That would open up a can of worms, with everyone in the world requesting
name changes. That would be pretty pointless and make the kernel all but
unmanageable.

Guenter

> However, I will send a patch to update the documentation in Kconfig.
> 
> 


  reply	other threads:[~2019-02-08  4:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14  2:36 [RFC PATCH 0/4] watchdog: hpwdt: Fix NMI-related behaviour when CONFIG_HPWDT_NMI_DECODING is enabled Ivan Mironov
2019-01-14  2:36 ` [RFC PATCH 1/4] watchdog: hpwdt: Don't disable watchdog on NMI Ivan Mironov
2019-01-16  2:27   ` Jerry Hoemann
2019-01-16  2:52     ` Guenter Roeck
2019-02-02  4:55     ` Ivan Mironov
2019-02-08  1:26       ` Jerry Hoemann
2019-02-08  4:17         ` Guenter Roeck [this message]
2019-02-14 19:49         ` Ivan Mironov
2019-01-14  2:36 ` [RFC PATCH 2/4] watchdog: hpwdt: Don't panic on foreign NMI Ivan Mironov
2019-01-14  2:36 ` [RFC PATCH 3/4] watchdog: hpwdt: Add more information into message Ivan Mironov
2019-01-14  2:36 ` [RFC PATCH 4/4] watchdog: hpwdt: Make panic behaviour configurable Ivan Mironov
2019-01-16  2:30   ` Jerry Hoemann
2019-02-02  5:13     ` Ivan Mironov
2019-01-16  2:22 ` [RFC PATCH 0/4] watchdog: hpwdt: Fix NMI-related behaviour when CONFIG_HPWDT_NMI_DECODING is enabled Jerry Hoemann
2019-02-02  6:24   ` Ivan Mironov

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=4f7de732-31cf-a220-f1eb-3d8182cf9c72@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Jerry.Hoemann@hpe.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=mironov.ivan@gmail.com \
    --cc=wim@linux-watchdog.org \
    /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).