Dnia 2021-03-15, o godz. 08:26:38 Matt Spinler <[email protected]> napisał(a):
> On 3/15/2021 7:00 AM, Rasmus Villemoes wrote: > > On 15/03/2021 12.16, [email protected] wrote: > >> Dnia 2021-03-15, o godz. 09:03:07 > >> It seems that the open-write-close-open sequence has been introduced in > >> busybox 1.28.0 by commit > >> https://git.busybox.net/busybox/commit/?h=31c765081dc41f158786545fbea9294be4685bd2 > >> > > Yeah, I could probably have spelled that out; I did cc the author of > > that commit. > >> AFAIU the commit message says that it is a kind of a workaround for some > >> possible implementations of hardware watchdogs, which could enter wrong > >> state when their supervisor in userspace is restarted (confused by > >> close/open? I don't know). But it doesn't name any single example of an > >> existing watchdog like that. > >> > >> In my case (softdog nowayout=1) that "fix" only adds: > >> - bloat to busybox, and > >> - annoying critical error message from kernel (yes, "watchdog: watchdog0: > >> watchdog did not stop!" is at KERN_CRIT level) > >> > >> So I'm definitely for making the behaviour introduced by commit > >> 31c765081dc41f158786545fbea9294be4685bd2 optional. > > Hi, I apologize 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. 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. I see there is a "start" method inside watchdog_ops (include/linux/watchdog.h). It is called by watchdog_dev during open(), for example. Maybe a properly written watchdog driver should do all the necessary re-initialization there instead of watchdog_ops.stop() method? Now the open-stop-close-open sequence seems like a workaround in userspace for some broken watchdog driver... -- _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
