Subject: Re: watchdog timer
To: Simon Burge <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 04/06/2003 21:04:53
In message <20030406231418.GA6286@thistledown.com.au>, Simon Burge writes:
>On Sat, Apr 05, 2003 at 04:12:04PM -0500, Steve Bellovin wrote:
>> Is there some built-in software watchdog timer? wdogctl(8) on 1.6
>> implies that there is; running wdogctl says that nothing is configured.
>> A quick grep didn't turn anything up, but it's a fairly obvious feature
>> to want -- am I missing something? (Or is that a hint that I should
>> write such a driver?)
>The wdogctl interface is meant for hardware watchdog timers. This is
>what wdogctl reports on a IBM PowerPC 405GP box:
> walnut# wdogctl
> Available watchdog timers:
> wdog0, 5 second period
>Setting the timer and disabling the tickle results in the CPU itself
>doing a hardware reset after the specified time.
>I'm not sure how you'd define a software watchdog timer (since by
>definition if the software is hosed it wont be able to tickle the
>software timer(!)), unless you mean you want something for userland
First -- yes, I'm mostly interested in a user-level tickle -- my
definition of "the system doesn't need to be rebooted" includes
"user-level programs can do something useful". I'm probably going to
write a generic software watchdog timer, and modify wdogctl to
optionally do some file I/O before resetting the timer.
Second, there are (at least) two ways to implement a software watchdog
timer. The most obvious is to use the callout mechanism; there's
clearly no point to doing that in the kernel. But -- on some platforms
-- callouts are done via a softintr call, and that runs at a much lower
priority than the hardware clock interrupt. There are many states
where a hardware clock interrupt can get through, but not a softinr.
If the watchdog timer is counted down by the hardware clock interrupt,
but tickled by the callout, there is still some benefit to a kernel
Sure, I'd rather have a pcweasel board. But at $350 for the PCI
version, it's rather beyond my budget for this project...
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)