From: Pratyush Anand <panand@redhat.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Timur Tabi <timur@codeaurora.org>,
fu.wei@linaro.org, Suravee.Suthikulpanit@amd.com, wim@iguana.be,
linux-arm-kernel@lists.infradead.org,
linux-watchdog@vger.kernel.org,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range
Date: Wed, 4 May 2016 19:44:49 +0530 [thread overview]
Message-ID: <20160504141449.GG13045@dhcppc6.redhat.com> (raw)
In-Reply-To: <20160503171602.GA2518@roeck-us.net>
Hi Guenter,
On 03/05/2016:10:16:02 AM, Guenter Roeck wrote:
> On Tue, May 03, 2016 at 09:21:41PM +0530, Pratyush Anand wrote:
> > On 03/05/2016:10:07:48 AM, Timur Tabi wrote:
> > > Pratyush Anand wrote:
> > > >In fact after supporting max_hw_heartbeat_ms, there should be no change for
> > > >action=0 functionally. However, we would still need some changes for action=1.
> > >
> > > IMHO, action=1 is more of a debugging option, and not something that would
> > > be used normally. I would need to see some evidence that real users want to
> > > have action=1 and a longer timeout.
> > >
> > If action=1 need to be used effectively, then we should have something which
> > would help to increase timeout values.
> >
> > Currently you have only 10 second to execute secondary kernel, which might not
> > be sufficient.
> >
> Previously the argument was that the 10 seconds (assuming the clock runs at
> maximum speed) would not be sufficient to load the watchdog application. Now it
May be you meant "would be sufficient". OK..let me clarify on it.
Currently it takes 7-8 second from the point 1st kernel panics to the point
second kernel boots. (Given, we have D-cache enabled in kexec-tools, for which
community is not yet agreed), anyway..so, it is safe for me as of now. But,
there is only 2-3 second margin. So, I am not sure if all sort of secondary
kernel will be able to make it in that time.
Following minimal code will be able to extend timeout for secondary kernel, and
I do not see anything wrong in it. We are anyway, panicking in ISR, so what
could be disadvantage if we write a wdt register just before panicking?
--- a/drivers/watchdog/sbsa_gwdt.c
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -221,6 +221,13 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
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");
return IRQ_HANDLED;
~Pratyush
WARNING: multiple messages have this Message-ID (diff)
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 19:44:49 +0530 [thread overview]
Message-ID: <20160504141449.GG13045@dhcppc6.redhat.com> (raw)
In-Reply-To: <20160503171602.GA2518@roeck-us.net>
Hi Guenter,
On 03/05/2016:10:16:02 AM, Guenter Roeck wrote:
> On Tue, May 03, 2016 at 09:21:41PM +0530, Pratyush Anand wrote:
> > On 03/05/2016:10:07:48 AM, Timur Tabi wrote:
> > > Pratyush Anand wrote:
> > > >In fact after supporting max_hw_heartbeat_ms, there should be no change for
> > > >action=0 functionally. However, we would still need some changes for action=1.
> > >
> > > IMHO, action=1 is more of a debugging option, and not something that would
> > > be used normally. I would need to see some evidence that real users want to
> > > have action=1 and a longer timeout.
> > >
> > If action=1 need to be used effectively, then we should have something which
> > would help to increase timeout values.
> >
> > Currently you have only 10 second to execute secondary kernel, which might not
> > be sufficient.
> >
> Previously the argument was that the 10 seconds (assuming the clock runs at
> maximum speed) would not be sufficient to load the watchdog application. Now it
May be you meant "would be sufficient". OK..let me clarify on it.
Currently it takes 7-8 second from the point 1st kernel panics to the point
second kernel boots. (Given, we have D-cache enabled in kexec-tools, for which
community is not yet agreed), anyway..so, it is safe for me as of now. But,
there is only 2-3 second margin. So, I am not sure if all sort of secondary
kernel will be able to make it in that time.
Following minimal code will be able to extend timeout for secondary kernel, and
I do not see anything wrong in it. We are anyway, panicking in ISR, so what
could be disadvantage if we write a wdt register just before panicking?
--- a/drivers/watchdog/sbsa_gwdt.c
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -221,6 +221,13 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
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");
return IRQ_HANDLED;
~Pratyush
next prev parent reply other threads:[~2016-05-04 14:14 UTC|newest]
Thread overview: 55+ 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 8:20 ` Pratyush Anand
2016-05-03 12:12 ` Timur Tabi
2016-05-03 12:12 ` Timur Tabi
2016-05-03 13:24 ` Pratyush Anand
2016-05-03 13:24 ` Pratyush Anand
2016-05-03 13:47 ` Guenter Roeck
2016-05-03 13:47 ` Guenter Roeck
2016-05-03 14:17 ` Pratyush Anand
2016-05-03 14:17 ` Pratyush Anand
2016-05-03 14:46 ` Guenter Roeck
2016-05-03 14:46 ` Guenter Roeck
2016-05-03 15:04 ` Timur Tabi
2016-05-03 15:04 ` Timur Tabi
2016-05-03 13:29 ` Guenter Roeck
2016-05-03 13:29 ` Guenter Roeck
2016-05-03 14:38 ` Pratyush Anand
2016-05-03 14:38 ` Pratyush Anand
2016-05-03 15:07 ` Timur Tabi
2016-05-03 15:07 ` Timur Tabi
2016-05-03 15:51 ` Pratyush Anand
2016-05-03 15:51 ` Pratyush Anand
2016-05-03 17:16 ` Guenter Roeck
2016-05-03 17:16 ` Guenter Roeck
2016-05-04 14:14 ` Pratyush Anand [this message]
2016-05-04 14:14 ` Pratyush Anand
2016-05-04 14:21 ` Timur Tabi
2016-05-04 14:21 ` Timur Tabi
2016-05-04 15:59 ` Pratyush Anand
2016-05-04 15:59 ` Pratyush Anand
2016-05-04 16:17 ` Timur Tabi
2016-05-04 16:17 ` Timur Tabi
2016-05-05 16:43 ` Guenter Roeck
2016-05-05 16:43 ` Guenter Roeck
2016-05-05 18:20 ` Pratyush Anand
2016-05-05 18:20 ` Pratyush Anand
2016-05-05 18:20 ` Pratyush Anand
2016-05-05 18:22 ` Timur Tabi
2016-05-05 18:22 ` Timur Tabi
2016-05-05 18:22 ` Timur Tabi
2016-05-05 23:36 ` Guenter Roeck
2016-05-05 23:36 ` Guenter Roeck
2016-05-05 23:36 ` Guenter Roeck
2016-05-05 23:38 ` Timur Tabi
2016-05-05 23:38 ` Timur Tabi
2016-05-05 23:38 ` Timur Tabi
2016-05-05 23:45 ` Timur Tabi
2016-05-05 23:45 ` Timur Tabi
2016-05-05 23:45 ` Timur Tabi
2016-05-06 0:18 ` Guenter Roeck
2016-05-06 0:18 ` Guenter Roeck
2016-05-06 0:18 ` Guenter Roeck
2016-05-05 23:51 ` Guenter Roeck
2016-05-05 23:51 ` 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=20160504141449.GG13045@dhcppc6.redhat.com \
--to=panand@redhat.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=fu.wei@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=timur@codeaurora.org \
--cc=wim@iguana.be \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.