AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070605103842.0ff7fbf0@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<tim.gardner@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E040203AD@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 5 Jun 2007 10:39:19 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Tim Gardner" <tim.gardner@onstor.com>
Subject: Re: watchdog device
Message-ID: <20070605103919.6df10e8d@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E040203AD@onstor-exch02.onstor.net>
References: <20070604161540.711da0db@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E1049D7@onstor-exch02.onstor.net>
	<20070605083854.06e4b50d@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E04020374@onstor-exch02.onstor.net>
	<20070605101359.3f05f35c@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0402038C@onstor-exch02.onstor.net>
	<20070605102049.0ebc9368@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E040203AD@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Unless some sync method is used, what would stop one process from
disabling it a microsecond before another enables it again?

On Tue, 5 Jun 2007 10:29:08 -0700 "Tim Gardner"
<tim.gardner@onstor.com> wrote:

> Mostly. But the chassis application does not behave this way and
> sends the syscalls directly. Not sure if other applications
> utilize the chassis library to also send syscalls directly.
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, June 05, 2007 10:21 AM
> To: Tim Gardner
> Subject: Re: watchdog device
> 
> Isn't it really only one process?  Other processes merely send
> messages to that process?  I can't imagine how it could possibly work
> reliably otherwise.
> 
> On Tue, 5 Jun 2007 10:15:43 -0700 "Tim Gardner"
> <tim.gardner@onstor.com> wrote:
> 
> > Yup. That is the current architecture and I don't want to make
> > unnecessary architecture changes.
> > 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Tuesday, June 05, 2007 10:14 AM
> > To: Tim Gardner
> > Subject: Re: watchdog device
> > 
> > Really?
> > 
> > On Tue, 5 Jun 2007 10:07:04 -0700 "Tim Gardner"
> > <tim.gardner@onstor.com> wrote:
> > 
> > > The watchdog needs to be disabled by multiple processes.
> > > 
> > > -----Original Message-----
> > > From: Andy Sharp 
> > > Sent: Tuesday, June 05, 2007 8:39 AM
> > > To: Tim Gardner
> > > Subject: Re: watchdog device
> > > 
> > > You can disable it simply by closing the file descriptor.
> > > 
> > > Cheers,
> > > 
> > > a
> > > 
> > > 
> > > On Mon, 4 Jun 2007 20:22:02 -0700 "Tim Gardner"
> > > <tim.gardner@onstor.com> wrote:
> > > 
> > > > Thanks Andy. Very close to what we want but not quite.
> > > > We need to be able to enable/disable the watchdog as well as set
> > > > the timeout value. I will probably just steal the source for
> > > > this driver and add a few ioctls.
> > > > 
> > > > ________________________________
> > > > 
> > > > From: Andy Sharp
> > > > Sent: Mon 6/4/2007 4:15 PM
> > > > To: Tim Gardner
> > > > Subject: watchdog device
> > > > 
> > > > 
> > > > 
> > > > Here is the kernel help text for the watchdog device.  You can
> > > > configure the software watchdog by adding support for
> > > > SOFT_WATCHDOG. CONFIG_WATCHDOG is already set to 'y'.  So, add a
> > > > line CONFIG_SOFT_WATCHDOG=y
> > > > after the CONFIG_WATCHDOG line in .config and do a 'make' in
> > > > linux-mips-2.6, or a 'make kernel-build' in the directory above
> > > > (cougar/linux/kernel).
> > > > 
> > > > The user process then has to open and write to the file
> > > > descriptor at least once a minute or the kernel will reboot.  I
> > > > haven't tested it ~:^)
> > > > 
> > > > 
> > > > CONFIG_WATCHDOG=y
> > > > 
> > > > If you say Y here (and to one of the following options) and
> > > > create a character special file /dev/watchdog with major number
> > > > 10 and minor number 130 using mknod ("man mknod"), you will get
> > > > a watchdog, i.e.: subsequently opening the file and then
> > > > failing to write to it for longer than 1 minute will result in
> > > > rebooting the machine. This could be useful for a networked
> > > > machine that needs to come back on-line as fast as possible
> > > > after a lock-up. There's both a watchdog implementation
> > > > entirely in software (which can sometimes fail to reboot the
> > > > machine) and a driver for hardware watchdog boards, which are
> > > > more robust and can also keep track of the temperature inside
> > > > your computer. For details, read
> > > > <file:Documentation/watchdog/watchdog.txt> in the kernel source.
> > > > 
> > > > The watchdog is usually used together with the watchdog daemon
> > > > which is available from
> > > > <ftp://ibiblio.org/pub/Linux/system/daemons/watchdog/>. This
> > > > daemon can also monitor NFS connections and can reboot the
> > > > machine when the process table is full.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > CONFIG_SOFT_WATCHDOG=[y|m]
> > > > 
> > > > A software monitoring watchdog. This will fail to reboot your
> > > > system from some situations that the hardware watchdog will
> > > > recover from. Equally it's a lot cheaper to install.
> > > > 
> > > > To compile this driver as a module, choose M here: the
> > > > module will be called softdog.
> > > > 
> > > > 
> > > > 
> > > > CONFIG_WATCHDOG_NOWAYOUT=n
> > > > 
> > > > The default watchdog behaviour (which you get if you say N here)
> > > > is to stop the timer if the process managing it closes the file
> > > > /dev/watchdog. It's always remotely possible that this process
> > > > might get killed. If you say Y here, the watchdog cannot be
> > > > stopped once it has been started.
> > > > 
> > > > 
