Hi Uwe,
On 08/05/2015 12:36 AM, Uwe Kleine-König wrote:
Hello Pádraig,
On Wed, Aug 05, 2015 at 12:43:39AM +0100, Pádraig Brady wrote:
On 04/08/15 03:13, Guenter Roeck wrote:
The watchdog infrastructure is currently purely passive, meaning
it only passes information from user space to drivers and vice versa.
Since watchdog hardware tends to have its own quirks, this can result
in quite complex watchdog drivers. A number of scanarios are especially common.
- A watchdog is always active and can not be disabled, or can not be disabled
once enabled. To support such hardware, watchdog drivers have to implement
their own timers and use those timers to trigger watchdog keepalives while
the watchdog device is not or not yet opened.
- A variant of this is the desire to enable a watchdog as soon as its driver
has been instantiated, to protect the system while it is still booting up,
but the watchdog daemon is not yet running.
Just mentioning that patting the watchdog in the boot loader
(by patching grub etc.) can be a more general solution here as it
avoids hangs if the kernel crashes before it runs the watchdog driver,
which is especially true if PXE loaded across the net for example.
Also this tends to be better spaced between boot start and user space loading.
the watchdog I'm currently working with on a powerpc platform has a
unchangable timeout of ~1 s. To make the machine boot I patched the
bootloader and need some automatic pinging in the kernel before
userspace takes over.
Does using arch_initcall in the watchdog driver help here, or is that
still too slow and you really need to hack the kernel ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
