From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Fraser To: "'fche@redhat.com'" , ecos-discuss@sources.redhat.com Subject: RE: [ECOS] Hardware Watchdog Date: Thu, 26 Jul 2001 07:27:00 -0000 Message-id: X-SW-Source: 2001-07/msg00828.html There are several opinions on this, so don't be surprised by disagreements. With a multi tasking OS, one could take two task based views. One: Stick it at the highest priority level (thread, process, whatever....) and the watchdog fires if the kernel crashes or stops scheduling for any reason. Two: Stick it at the lowest priority level and the watchdog will fire in any starvation situation. There are good and bad points for either, and I won't argue them here. (the list is arbitrary and HUGE!) In either case, a still running system can make other decisions about its own health and kill or block the watchdog thread, forcing a reset. You might even consider adding a rendezvous point to the watchdog thread. On acknowledging the watchdog from an interrupt... Depending on you interrupt structure, you should not associate it with an interrupt. The reason being that on many systems, the interrupts will continue to fire even if the kernel is dead or scheduling has ceased. That would be bad if your periodic timer interrupt was hammering away happily on your otherwise dead system, keeping the much needed watchdog at bay. Doug > -----Original Message----- > From: fche@redhat.com [ mailto:fche@redhat.com ] > Sent: Thursday, July 26, 2001 7:57 AM > To: ecos-discuss@sources.redhat.com > Subject: Re: [ECOS] Hardware Watchdog > > > Content-Type: text/plain; charset=US-ASCII > From: fche@redhat.com (Frank Ch. Eigler) > Date: 26 Jul 2001 07:56:53 -0400 > In-Reply-To: < 20010726125313.A14929@frequentis.com > > Message-ID: > Lines: 23 > User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) > MIME-Version: 1.0 > > Christoph Csebits writes: > > : [...] > : im having a MPC860T based board with > : an hardware watchdog on it. > : [...] > : In eCos applications i am having a > : separate thread triggering the watchdog. > : No problem. > : [...] > : What do you think about using some > : of the timer interrupts for generating > : the watchdog triggers. > > Is it typical to put watchdog reset calls into separate dedicated > threads, or low-level automatically-invoked code like interrupt > handlers? I was under the impression that watchdog resets are most > appropriately placed within the activity loops of the application code > itself -- it is their demise that the watchdog mechanism is meant to > detect. > > > - FChE >