From: jiri.prchal@aksignal.cz (Jiří Prchal)
To: linux-arm-kernel@lists.infradead.org
Subject: at91sam9: watchdog: period
Date: Wed, 7 Oct 2015 09:16:52 +0200 [thread overview]
Message-ID: <5614C6E4.20808@aksignal.cz> (raw)
In-Reply-To: <20151006180342.GA13434@gradator.net>
Thanks Sylvain,
good explanation, now it's clear for me.
It works!
The problem is SOLVED!
On 6.10.2015 20:03, Sylvain Rochet wrote:
> Hi Ji??,
>
> On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote:
>> Hi all,
>> I'm trying to discover what's wrong with watchdog on my board. I didn't find
>> anything about it on internet so I would ask you for help.
>> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors
>> to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely
>> powered from backup and main power too (no NTP). But watchdog time to reset
>> is still 61s regardless default (16s) or 4s heartbeat setting. No change to
>> WDT_MR in bootstrap, so in Linux should work.
>
> I'm a bit late here but it looks like there is a misunderstanding about
> the watchdog stack involved here:
>
> userland
> ------- /dev/watchdog0 ------
> watchdog0
> -> userland wanted reset time value
> -> userland wanted ping time value
> ------- internal kernel watchdog interface ------
> atmel,at91sam9260-wdt
> -> atmel,min-heartbeat-sec
> -> atmel,max-heartbeat-sec
>
> watchdog0 is the software interface, controlled by your userland, is it
> always on top of the hardware watchdog and it calls the watchdog_ops
> hooks, like watchdog_ops->start(), watchdog_ops->stop(), or
> watchdog_ops->set_timeout() for this driver depending on the userland
> willingness to (re)start, stop the watchdog or change the hardware
> timeout value.
>
> watchdog0 have two configurable values, reset time and ping time, the
> default is 60s for timeout and 30s for ping (the 61s you are
> seeing is the default timeout value).
>
> For example, the watchdog binary from BusyBox allows you to set the
> watchdog0 reset and ping time using -T and -t arguments:
> -T N Reboot after N seconds if not reset (default 60)
> -t N Reset every N seconds (default 30)
>
> The -T value is sent to the hardware driver using the
> watchdog_ops->set_timeout() hook. The -t value is how often you want the
> watchdog to be (re)started using the watchdog_ops->start() hook.
>
> In a perfect world, the watchdog_ops->set_timeout() hook should be able
> to precisely set the hardware timeout you want, but there is two
> problems here:
>
> - 60 secs timeout is more than supported by this hardware watchdog,
> which have a maximum timeout value of 16 secs. The driver is able to
> return to userland that wanted values are not acceptable, but it would
> means the default watchdog values wouldn't work.
>
> - This hardware watchdog is a bit special: its period cannot be
> changed once started, usually the hardware timeout follows the watchdog0
> timeout value wanted by userspace but that's not possible here. That's
> why this driver is using its own heartbeat software timer to reset the
> hardware watchdog more often than actually asked by userland. Thus,
> because we are resetting on your own the hardware watchdog it means that
> once the software watchdog embedded into this driver expire there is
> still the hardware watchdog to expire.
>
> We try to reset the watchdog counter 4 or 2 times more often than
> actually requested, in order to avoid spurious watchdog reset. For the 4
> times case (the default), we get a hardware timeout between 12 and 16
> secs.
>
> Conclusion, if you want a fast reset, you have to use a lower
> atmel,max-heartbeat-sec value as well as using low values for the
> timeouts values passed to kernel through the watchdog interface
> "watchdog -T -t".
>
> I wonder if we should substract from the watchdog_ops->set_timeout()
> new_timeout argument value the previously set hardware timeout period,
> this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16"
> watchdog timeout. If someone agree I will propose a patch to do that.
>
>
>> / # killall watchdog
>> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
>> [ 1821.123123] watchdog watchdog0: watchdog did not stop!
>
> 60 seconds software timeout, this is the default set by userland tools.
>
>> [ 1882.294294] at91sam9_wdt: I will reset your machine !
>
> Then 12 to 16 seconds timeout, this is the hardware timeout.
>
>
> Sylvain
>
next prev parent reply other threads:[~2015-10-07 7:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal
2015-05-15 13:59 ` Bryan Evenson
2015-05-15 14:19 ` Nicolas Ferre
2015-05-18 6:25 ` Jiří Prchal
2015-05-15 15:25 ` Boris Brezillon
2015-05-18 6:27 ` Jiří Prchal
2015-05-18 7:27 ` Boris Brezillon
2015-05-18 8:17 ` Jiří Prchal
2015-05-19 3:07 ` Yang, Wenyou
2015-05-19 7:14 ` Boris Brezillon
2015-05-19 9:01 ` Jiří Prchal
2015-05-19 9:14 ` Boris Brezillon
2015-05-19 9:52 ` Jiří Prchal
2015-05-19 10:04 ` Boris Brezillon
2015-05-20 12:39 ` Jiří Prchal
2015-05-21 12:41 ` Jiří Prchal
2015-05-27 7:11 ` Jiří Prchal
2015-05-19 7:12 ` Boris Brezillon
2015-05-19 9:00 ` Jiří Prchal
2015-10-06 13:07 ` Jiří Prchal
2015-10-06 18:03 ` Sylvain Rochet
2015-10-07 7:16 ` Jiří Prchal [this message]
2015-10-07 9:22 ` Sylvain Rochet
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=5614C6E4.20808@aksignal.cz \
--to=jiri.prchal@aksignal.cz \
--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).