From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Zickus Subject: Re: [PATCH 3/4] watchdog: Split up config options Date: Thu, 15 Jun 2017 11:51:22 -0400 Message-ID: <20170615155122.exwji7lkurfjvmzn@redhat.com> References: <20170603161005.279fe0ef@roar.ozlabs.ibm.com> <20170606164958.lkwy7t7xzdpxg4mp@redhat.com> <20170607135026.1a6129a8@roar.ozlabs.ibm.com> <20170608160502.uzp7vmr7s4fj6hjm@redhat.com> <20170612180739.1aa4b123@roar.ozlabs.ibm.com> <20170612204156.ov7ka2765t4gdakl@redhat.com> <20170614021118.4bbfd00f@roar.ozlabs.ibm.com> <20170614140937.qrkajknqxldwdkv2@redhat.com> <20170615130401.033a39dd@roar.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38022 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750737AbdFOPvY (ORCPT ); Thu, 15 Jun 2017 11:51:24 -0400 Content-Disposition: inline In-Reply-To: <20170615130401.033a39dd@roar.ozlabs.ibm.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Nicholas Piggin Cc: Babu Moger , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org On Thu, Jun 15, 2017 at 01:04:01PM +1000, Nicholas Piggin wrote: > > +#ifdef CONFIG_HARDLOCKUP_DETECTOR > > /* boot commands */ > > /* > > * Should we panic when a soft-lockup or hard-lockup occurs: > > @@ -69,9 +73,6 @@ static int __init hardlockup_panic_setup(char *str) > > return 1; > > } > > __setup("nmi_watchdog=", hardlockup_panic_setup); > > - > > -#else > > -unsigned long __read_mostly watchdog_enabled = SOFT_WATCHDOG_ENABLED; > > #endif > > > > #ifdef CONFIG_SOFTLOCKUP_DETECTOR > > Hmm, I guess I missed this because sparc parses nmi_watchdog=, but it > also relies on the watchdog_enabled value. > > I guess I can fold your incremental patch in. I hope we could get > sparc quickly to adopt the complate HAVE_HARDLOCKUP_DETECTOR_ARCH soon > afterwards though, so we only have 2 cases -- complete hardlockup > detector, or the very bare minimum NMI_WATCHDOG. Hi Nick, I agree. Let's move forward with this temp fix just to get things in the kernel for initial testing. Then follow up with a cleanup patch. The idea is we can always revert the cleanup patch if things still don't quite work. Thoughts? Cheers, Don