This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Hardware Watchdog


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: <o5ofq7ucmy.fsf@touchme.toronto.redhat.com>
> Lines: 23
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
> MIME-Version: 1.0
> 
> Christoph Csebits <christoph.csebits@frequentis.com> 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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]