On 3/17/2021 3:42 PM, Rasmus Villemoes wrote:
On 15/03/2021 23.41, [email protected] wrote:
Dnia 2021-03-15, o godz. 08:26:38
Matt Spinler <[email protected]> napisał(a):
for not responding sooner.
In my case, the code is on a BMC (OpenBMC), and the output of the
watchdog is wired to a fan watchdog hardware circuit (involving a latch
and a standalone fan control chip), which the watchdog app is pinging.
So if the watchdog app dies the fans get set to full speed, however on
the next main power cycle of the server (the BMC is on a different power
domain) we want things back to normal, so the watchdog has to work again
when it is restarted, which it wasn't doing without my change.
Thanks for the explanation. Can you point me at the watchdog driver code
which does this "get things back to normal" on a (graceful) shutdown/stop?
Our hardware is an ASPEED BMC chip, and here is the driver:
https://github.com/torvalds/linux/blob/master/drivers/watchdog/aspeed_wdt.c
I wonder what is the "architecturally correct" way of fixing this kind of problem, since doing
"stop" as a way to "start" seems counter-intuitive.
Indeed.
Denys, can you consider applying the up-thread patch. Whether you'll
make it default n or y is up to you. Even if it's n, I think one can
achieve the same thing with a wrapper
#!/bin/sh
( shift $(($# - 1)) && [ -c "$1" ] && printf 'V' > "$1" )
exec busybox watchdog "$@"
(or in any other number of ways, depending on how one starts the
daemon). But there is no way of avoiding the annoying "nowayout"
messages from the kernel if busybox is built with this
open-write-close-open.
Rasmus
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
