public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Doug Fraser <dfraser@photuris.com>
To: "'fche@redhat.com'" <fche@redhat.com>, ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] Hardware Watchdog
Date: Thu, 26 Jul 2001 07:27:00 -0000	[thread overview]
Message-ID: <E2D27064CD59574F88D05AEF5728396D445411@PH01SRV02.photuris.com> (raw)

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
> 

             reply	other threads:[~2001-07-26  7:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-26  7:27 Doug Fraser [this message]
2001-07-26  7:51 ` Christoph Csebits
2001-07-26  8:50   ` Gary Thomas
2001-07-26  9:20     ` Christoph Csebits
2001-07-26  9:25       ` Gary Thomas
2001-07-26 11:30       ` Robin Farine
2001-07-26 23:26         ` Christoph Csebits
2001-07-26 23:57           ` Robin Farine
2001-07-27  1:28             ` Christoph Csebits
2001-07-27  1:50               ` Robin Farine
2001-07-27  2:50               ` [ECOS] RedBoot RAM version problem Andre Sebastien
2001-07-27  3:35                 ` Jesper Skov
2001-07-27  5:20                   ` Andre Sebastien
2001-07-27  6:20                     ` Jesper Skov
2001-07-27  7:30                       ` Andre Sebastien
2001-07-27  7:54                         ` Gary Thomas
2001-07-30  1:38                           ` Andre Sebastien
2001-07-30  1:57                             ` Jesper Skov
2001-07-30  2:29                               ` Andre Sebastien
2001-07-30  3:03                                 ` Jesper Skov
2001-07-30  3:07                                   ` Andre Sebastien
  -- strict thread matches above, loose matches on Subject: below --
2001-07-26 13:21 [ECOS] Hardware Watchdog Doug Fraser
2001-07-26 10:02 Doug Fraser
2001-07-26 10:13 ` Gary Thomas
2001-07-26  3:55 Christoph Csebits
2001-07-26  4:58 ` fche

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=E2D27064CD59574F88D05AEF5728396D445411@PH01SRV02.photuris.com \
    --to=dfraser@photuris.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=fche@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).