/dev/watchdog for onchip MPC860 watchdog?

Graham Stoney greyham at research.canon.com.au
Thu Oct 21 13:49:41 EST 1999

> From: Dan Malek <dan at netx4.com>
> To: Graham Stoney <greyham at research.canon.com.au>
> Cc: Dan Malek <dan at penguin.netx4.com>;
> <linuxppc-embedded at lists.linuxppc.org>
> Sent: Tuesday, October 19, 1999 3:51 PM
> Subject: Re: /dev/watchdog for onchip MPC860 watchdog?
> > Graham Stoney wrote:
> > > .... The watchdog can't
> > > be disabled/reenabled, and its maximum period is only a couple of
> seconds;
> > > there's no guarantee that the kernel will have booted and loaded the
> > > application by then, so the watchdog is likely to go off during the boot
> > > process. I think this probably puts my plans to use it on hold for
> now...
> >
> > Maybe not.  I was thinking about this (when I should have been doing
> > other things :-) earlier today.  What we could do when the internal
> > watchdog is configured is to service it during the Linux timer
> > interrupt when an application doesn't have it "enabled".  This
> > doesn't provide a watchdog service, just ensures it doesn't
> > unexpectedly expire.  When an application decides it wants the
> > watchdog, we don't service it in the timer ISR.
> >
> > We would have to litter the boot code with some service calls,
> > like when you wait at the Linux boot prompt, and make sure
> > you can uncompress and enable timer interrupts before the next
> > expiration.  Beyond that, we wouldn't have to look for any
> > watchdog service points in the kernel.

Our email & file server died big time yesterday, so I only saw this this
morning, and co-incidentally had exactly the same idea. To the user app,
/dev/watchdog still looks much like the interface in watchdog.txt.

Sounds pretty good to me!


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-embedded mailing list