Messages in this thread | | | Subject | Re: [RFC PATCH 1/4] watchdog: hpwdt: Don't disable watchdog on NMI | From | Guenter Roeck <> | Date | Thu, 7 Feb 2019 20:17:29 -0800 |
| |
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. > >
| |