Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Stefan Roese]

I'm trying to implement support for a board specific watchdog on a PPC440EPx 
board with a very short timeout. In this case, the watchdog has to 
be "kicked" at least every 100ms, even while booting and the real watchdog 
driver not running yet. While looking for trigger places in the kernel 
source, I noticed the already existing "touch_nmi_watchdog()" function, which 
seems to be doing what I need. Even if the name not exactly matches my 
hardware setup.

My question now is, is it recommended to use this 
touch_nmi_watchdog() "infrastructure" for my PPC custom specific watchdog 
during bootup? And if yes, should it perhaps be renamed to a more generic 
name, like "touch_watchdog"?

Please advise. Thanks.

Best regards,
Stefan

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Lennart Sorensen]

On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> I'm trying to implement support for a board specific watchdog on a PPC440EPx 
> board with a very short timeout. In this case, the watchdog has to 
> be "kicked" at least every 100ms, even while booting and the real watchdog 
> driver not running yet. While looking for trigger places in the kernel 
> source, I noticed the already existing "touch_nmi_watchdog()" function, which 
> seems to be doing what I need. Even if the name not exactly matches my 
> hardware setup.
> 
> My question now is, is it recommended to use this 
> touch_nmi_watchdog() "infrastructure" for my PPC custom specific watchdog 
> during bootup? And if yes, should it perhaps be renamed to a more generic 
> name, like "touch_watchdog"?
> 
> Please advise. Thanks.

No idea really.  Who would design a watchdog with such a short trigger
time?  That doesn't seem to be useful in any way.

--
Len Sorensen

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Josh Boyer]

On Mon, 29 Oct 2007 15:45:03 -0400
lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > I'm trying to implement support for a board specific watchdog on a PPC440EPx 
> > board with a very short timeout. In this case, the watchdog has to 
> > be "kicked" at least every 100ms, even while booting and the real watchdog 
> > driver not running yet. While looking for trigger places in the kernel 
> > source, I noticed the already existing "touch_nmi_watchdog()" function, which 
> > seems to be doing what I need. Even if the name not exactly matches my 
> > hardware setup.
> > 
> > My question now is, is it recommended to use this 
> > touch_nmi_watchdog() "infrastructure" for my PPC custom specific watchdog 
> > during bootup? And if yes, should it perhaps be renamed to a more generic 
> > name, like "touch_watchdog"?
> > 
> > Please advise. Thanks.
> 
> No idea really.  Who would design a watchdog with such a short trigger
> time?  That doesn't seem to be useful in any way.

To some degree, it's configurable.  But the generic question still
stands.  It seems like a decent idea to me.  Making touch_watchdog (or
whatever it winds up being called) nice across arches might be fun.

josh

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Stefan Roese]

[added linuxppc-dev since it's PPC relevant too]

On Tuesday 30 October 2007, Josh Boyer wrote:
> On Mon, 29 Oct 2007 15:45:03 -0400
>
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> > On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > > I'm trying to implement support for a board specific watchdog on a
> > > PPC440EPx board with a very short timeout. In this case, the watchdog
> > > has to be "kicked" at least every 100ms, even while booting and the
> > > real watchdog driver not running yet. While looking for trigger places
> > > in the kernel source, I noticed the already existing
> > > "touch_nmi_watchdog()" function, which seems to be doing what I need.
> > > Even if the name not exactly matches my hardware setup.
> > >
> > > My question now is, is it recommended to use this
> > > touch_nmi_watchdog() "infrastructure" for my PPC custom specific
> > > watchdog during bootup? And if yes, should it perhaps be renamed to a
> > > more generic name, like "touch_watchdog"?
> > >
> > > Please advise. Thanks.
> >
> > No idea really.  Who would design a watchdog with such a short trigger
> > time?  That doesn't seem to be useful in any way.

It definitely is useful in our case, since its a requirement for 
this "critical" project. It's not needed to have such a short trigger time 
while booting, but unfortunately this external watchdog only supports one 
fixed timeout.

> To some degree, it's configurable.

No, I'm afraid it's not configurable in this case.

> But the generic question still 
> stands.  It seems like a decent idea to me.  Making touch_watchdog (or
> whatever it winds up being called) nice across arches might be fun.

I already have it running on my system using a quick hack (see patch below) in 
include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean 
implementation, that has chances for upstream merge (in arch/powerpc later), 
I would really like to hear if I should move on further this way. 

My impression is, that changing the name from touch_nmi_watchdog() to 
something like touch_watchdog(), and therefore touching lots of files, makes 
it more unlikely that this resulting patch will get accepted. But 
implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h 
header seems also not totally correct, since it's not really an NMI in this 
case.

Any thoughts on this?

Thanks.

Best regards,
Stefan

diff --git a/include/asm-ppc/nmi.h b/include/asm-ppc/nmi.h
new file mode 100644
index 0000000..f18862b
--- /dev/null
+++ b/include/asm-ppc/nmi.h
@@ -0,0 +1,16 @@
+/*
+ *  linux/include/asm-ppc/nmi.h
+ */
+#ifndef ASM_NMI_H
+#define ASM_NMI_H
+
+#ifdef BOARD_WATCHDOG_FUNC
+#define touch_nmi_watchdog	BOARD_WATCHDOG_FUNC
+#else
+static inline void touch_nmi_watchdog(void)
+{
+	touch_softlockup_watchdog();
+}
+#endif
+
+#endif /* ASM_NMI_H */

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Wolfgang Denk]

Hello Stefan,

In message <200710301216.15033.stefan.roese@gmail.com> you wrote:
>
> I already have it running on my system using a quick hack (see patch below) in 
> include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean 
> implementation, that has chances for upstream merge (in arch/powerpc later), 
> I would really like to hear if I should move on further this way. 
> 
> My impression is, that changing the name from touch_nmi_watchdog() to 
> something like touch_watchdog(), and therefore touching lots of files, makes 
> it more unlikely that this resulting patch will get accepted. But 
> implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h 
> header seems also not totally correct, since it's not really an NMI in this 
> case.

Indeed. Using the header file <asm/nmi.h> is seriously misleading for
the PowerPC version, as is the function name touch_nmi_watchdog() -
thius has nothing to do with NMIs on PowerPC, and most probably not on
any other non-x86 architecture as well. 

To make this mechanism generally usable (which is a good idea IMO) the
names should be changed to get rid of the "nmi" reference.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It may be that your whole purpose in life is simply  to  serve  as  a
warning to others.

Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)

[Lennart Sorensen]

On Mon, Oct 29, 2007 at 09:54:54PM -0500, Josh Boyer wrote:
> To some degree, it's configurable.  But the generic question still
> stands.  It seems like a decent idea to me.  Making touch_watchdog (or
> whatever it winds up being called) nice across arches might be fun.

It always seemed to me that it was userspace that should poke the
watchdog as an indication user space still works on the system.  That's
how my watchdogs are managed.  I do initialize them in the boot loader
with a 3 minute timeout which is more than long enough for the system to
boot, load the driver and change the timeout to 60 seconds or whatever
I want at runtime and start the watchdog daemon.

If the kernel hangs at initializing some driver, I do NOT want the
kernel to automatically be poking the watchdog.  I want it to time out
so to me the kernel should not be able to kick the watchdog at all by
itself.

--
Len Sorensen