From: Wim Van Sebroeck <wim@iguana.be>
To: Marc Vertes <marc.vertes@sigfox.com>
Cc: w.sang@pengutronix.de, linux-watchdog@vger.kernel.org,
linux-kernel@vger.kernel.org, HaraldWelte@viatech.com,
broonie@opensource.wolfsonmicro.com
Subject: Re: [PATCH RFC] watchdog: add a new driver for VIA chipsets
Date: Thu, 24 Nov 2011 16:48:47 +0100 [thread overview]
Message-ID: <20111124154847.GT23376@infomag.iguana.be> (raw)
In-Reply-To: <4ece57c9.2i1u841q3U3s+xD7%marc.vertes@sigfox.com>
Hi Marc,
> The smallest possible value is 1 second, both in BIOS and datasheet. For
> info, the maximum value is 1023 seconds, approx. 17 min.
Good that means that the driver value is allready OK.
> I think it is dangerous to set the timer to 1s, both in BIOS, obviously
> as the boot is still in progress when it expires, and even in the driver,
> where you loose a chance to avoid mandatory reboot after only 1 second
> of latency, even if the hardware timer is higher.
>
> The value you have set, 15 seconds, is reasonable to me, and should not
> be lowered. If the BIOS was well designed, it should also not allow less
> than, say 1 minute.
I have the feeling that you don't understand the function of the timer...
The timer actually sperates the userspace timeout from the watchdog's heartbeat.
The watchdog's heartbeat is what the hardware is actually using as it's timeout
value. That is the 1 second minimum in this case. if userspace is not using
the watchdog device then the timer will make sure that the watchdog is being
reset each 1/2 seconds (or 500ms). We use the smallest value because we don't
know what the actual value is and need to be safe. I do agree that you should
set this higher in the BIOS to survice the actual boot sequence, but we should
make sure that we reset regularly enough so that the system doesn't reboot in
normal operation. That's why I needed to know the minimum value.
The userspace timeout is the timeout that the watchdog daemon will use.
Meaning: in this time period the daemon needs to ping the watchdog, if not
the system should reboot. So how does the timer do this? When userspace opens
the watchdog (and thus takes control) the timer will know that we should
receive a ping between now and now+timeout. In this period the timer will
reset the watchdog each 500ms (the 1/2 seconds=half of the heartbeat time).
when we are at now+timeout and we did not receive a ping the timer will stop
resetting the watchdog, which will result in a reboot (after expiration of
watchdog's real heartbeat). If in the period between now and now+timeout
userspace did receive a ping, then the timer will now that now+timeout can
be replaced by new_now+timeout. And that's how it works. So the userspace
timeout has no real relation with the watchdog's heartbeat.
Or in short the timer does the following:
1) when /dev/watchdog is not opened by the watchdog dameon, it should reset
the watchdog hardware so that the system doesn't reboot.
2) when /dev/watchdog is opened by the watchdog dameon, it needs to reset
the watchdog hardware so that the system does not reboot unless we didn't
receive a ping in the timeout period. In that case the system should be
rebooted (and we do this by not resetting the watchdog anymore).
Hope this is clearer now.
Extra remark: the value in the BIOS should indeed be chosen with some
common sense: you need to survice the boot sequence, but if the heartbeat
is much higher then the timeout value, then you're system will not reboot
before the heartbeat has passed away (which means that the heartbeat of
your system will dominate anyway).
I think we should change the default timeout value to 60 seconds instead of 15.
Kind regards,
Wim.
next prev parent reply other threads:[~2011-11-24 15:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 11:17 Marc Vertes
2011-11-22 11:22 ` Wolfram Sang
2011-11-22 12:56 ` Rahul Bedarkar
2011-11-22 17:05 ` Marc Vertes
2011-11-22 17:30 ` Wolfram Sang
2011-11-22 18:09 ` Marc Vertes
2011-11-22 18:55 ` Marc Vertes
2011-11-23 12:10 ` Dmitry Artamonow
2011-11-23 14:12 ` Marc Vertes
2011-11-23 14:37 ` Mark Brown
2011-11-23 19:25 ` Dmitry Artamonow
2011-11-23 21:43 ` Wolfram Sang
2011-11-23 18:22 ` Harald Welte
2011-11-23 21:41 ` Wim Van Sebroeck
2011-11-24 19:22 ` Marc Vertes
2011-11-24 19:34 ` Wim Van Sebroeck
2011-11-25 20:02 ` Marc Vertes
2011-11-22 17:32 ` Mark Brown
2011-11-22 18:40 ` Wolfram Sang
2011-11-23 9:59 ` Marc Vertes
2011-11-23 10:49 ` Wolfram Sang
2011-11-23 11:43 ` Marc Vertes
2011-11-23 12:13 ` Wim Van Sebroeck
2011-11-23 12:20 ` Mark Brown
2011-11-23 12:40 ` Wim Van Sebroeck
2011-11-23 14:46 ` Marc Vertes
2011-11-23 21:43 ` Wim Van Sebroeck
2011-11-23 21:52 ` Wolfram Sang
2011-11-24 8:29 ` Wim Van Sebroeck
2011-11-23 21:46 ` Wim Van Sebroeck
2011-11-24 10:57 ` Marc Vertes
2011-11-24 13:42 ` Wim Van Sebroeck
2011-11-24 14:42 ` Marc Vertes
2011-11-24 15:48 ` Wim Van Sebroeck [this message]
2011-11-24 16:47 ` Marc Vertes
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=20111124154847.GT23376@infomag.iguana.be \
--to=wim@iguana.be \
--cc=HaraldWelte@viatech.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=marc.vertes@sigfox.com \
--cc=w.sang@pengutronix.de \
/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
all inboxes | Powered by JetHome®