From: panand@redhat.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range
Date: Wed, 4 May 2016 21:29:32 +0530 [thread overview]
Message-ID: <20160504155932.GH13045@dhcppc6.redhat.com> (raw)
In-Reply-To: <572A0577.1070000@codeaurora.org>
+Dave
Hi Timur,
On 04/05/2016:09:21:43 AM, Timur Tabi wrote:
> Pratyush Anand wrote:
> >static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> >{
> >+ struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
> >+ struct watchdog_device *wdd = &gwdt->wdd;
> >+ u64 timeout = (u64)gwdt->clk * wdd->timeout;
> >+
> >+ writeq(timeout + arch_counter_get_cntvct(),
> >+ gwdt->control_base + SBSA_GWDT_WCV);
> >+
> > panic(WATCHDOG_NAME " timeout");
>
> I'm on the fence about this.
>
> On one hand, I have always opposed the idea that the interrupt handler needs
> to function properly in order for the timeout to be correct. Fu's original
> patch required this for every timeout.
>
> The current code, however, only uses the interrupt when action=1. In this
> case, WCV is only reprogrammed in order to prevent the system from resetting
> during the kexec. Technically, the watchdog timeout has already been
> handled.
Yes.
>
> However, this should be unnecessary, because it can't be a problem that's
> unique to the SBSA watchdog. Every system that kexecs another kernel needs
> to be able to handle a watchdog timeout. Shouldn't the kexec code already
> ping or disable the watchdog? We need a cross-platform solution. Drivers
> should not need to do this.
Its unique to SBSA because you have very little timeout here. kexec-tools
upstream does not have any mechanism to handle watchdog timeout. Lets say even
if we implement a framework there, the best it can do is to ping the watchdog
again. Disabling should not be an option in kexec-tools, because in that case if
kexec-tools or secondary kernel stuck, we won't have a way out.
Now, even if we ping it once in kexec tools, we will have to make sure that
watchdog driver's probe is called before timeout. Therefore, user must have a
way to specify this timeout, so that if a particular kernel take more time to
boot then he can increase the timeout. Given, these variable conditions I do not
see much advantage of implementing it in kexec-tools.
However fedora/rhel kedumpctl mechanism does some best case correction. It
makes sure that watchdog module is loaded in second kernel if watchdog was
active during first kernel, and loaded as early as possible [1].
~Pratyush
[1] https://github.com/pratyushanand/kexec-tools/commits/watchdog_fmaster
next prev parent reply other threads:[~2016-05-04 15:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-03 8:20 [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range Pratyush Anand
2016-05-03 12:12 ` Timur Tabi
2016-05-03 13:24 ` Pratyush Anand
2016-05-03 13:47 ` Guenter Roeck
2016-05-03 14:17 ` Pratyush Anand
2016-05-03 14:46 ` Guenter Roeck
2016-05-03 15:04 ` Timur Tabi
2016-05-03 13:29 ` Guenter Roeck
2016-05-03 14:38 ` Pratyush Anand
2016-05-03 15:07 ` Timur Tabi
2016-05-03 15:51 ` Pratyush Anand
2016-05-03 17:16 ` Guenter Roeck
2016-05-04 14:14 ` Pratyush Anand
2016-05-04 14:21 ` Timur Tabi
2016-05-04 15:59 ` Pratyush Anand [this message]
2016-05-04 16:17 ` Timur Tabi
2016-05-05 16:43 ` Guenter Roeck
2016-05-05 18:20 ` Pratyush Anand
2016-05-05 18:22 ` Timur Tabi
2016-05-05 23:36 ` Guenter Roeck
2016-05-05 23:38 ` Timur Tabi
2016-05-05 23:45 ` Timur Tabi
2016-05-06 0:18 ` Guenter Roeck
2016-05-05 23:51 ` Guenter Roeck
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=20160504155932.GH13045@dhcppc6.redhat.com \
--to=panand@redhat.com \
--cc=linux-arm-kernel@lists.infradead.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).