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
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
On Mon, 29 Oct 2007 15:45:03 -0400
[email protected] (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
[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
>
> [email protected] (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 */
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
Hello Stefan,
In message <[email protected]> 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: [email protected]
It may be that your whole purpose in life is simply to serve as a
warning to others.