Date: Sun, 31 Dec 2017 15:52:20 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: karels@freebsd.org, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: making SW_WATCHDOG dynamic Message-ID: <CANCZdfriiUwiL6u2aXCVvC6=A=2Evbt_EYPC8gBX%2B4%2BTiU%2Bx1w@mail.gmail.com> In-Reply-To: <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> References: <201712311503.vBVF3DqQ040555@mail.karels.net> <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 31, 2017 at 11:01 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > My proposed change is in Phabricator, https://reviews.freebsd.org/D13713 > . > > > > A couple of notes: > > > > - I retained the SW_WATCHDOG option; it now just enables the software > > watchdog even if a hardware watchdog is attached, as it would have done > > in the past. > The SW_WATCHDOG option has changed in function, it use to control > if this code was compiled in at all, it now does something different. > This code is compile in now no matter what with no option to remove > it, which means there is one more rarely used option in the GENERIC > kernel that can not be removed. 1 byte or 100 does not matter, it > is that policy has been shoved down the users throat. "You shall have > a software watchdog timer in your kernel weither you want it there > or not, and it is turned off by default." > > We have way to many of those types of things already, > adding to this list is going in the wrong direction. Except the code does nothing of the sort. All it does is allow one to enable software watchdogs if one wants as an always-available (but off by default) feature. I don't see what the big deal is. If you don't enable watchdogd, things are exactly as before. If you do enable it, you don't have to rebuild a kernel to get it going. This isn't worth a fight. Warner > > > I updated NOTES and the watchdog(4) information accordingly. > > This change as it stands requires a RELNOTES flag. > > > I did not provide for any other combination of watchdogs or actions; that > > would require a complete rework of the kernel API. Note that the > hardware > > watchdogs provide no choice of action; they simply reset the box. > > > > - I have tested this with and without the SW_WATCHDOG option, but do not > > have a hardware watchdog to test with. If someone could test this, it > would > > be much apprectiated. I tested by enabling watchdogd with default > parameters, > > doing b"killall -STOP watchdogd", and then observing that the system > dropped > > into the debugger after about 128 sec. It drops into the debugger if KDB > > is defined and KDB_UNATTENDED is not; otherise it panics (as before). > > > > I neglected to respond this this from Andriy Gapon: > > > P.S. > > > And maybe just using the second software watchdog would be good enough > for what > > > you are doing? > > > > I think the hardclock-based SW_WATCHDOG is better than the --softtimeout > > wactchdog because it runs at a lower level (hardclock vs > callout/softclock). > > In particular, I have found it to work in situations where a locking > > deadly embrace started in the network stack, and then a callout routine > > got stuck as well when a function it called blocked on the offending > lock. > > That caused watchdogd to fail to be rescheduled, and the watchdog fired > as > > a result. The callout-based facility could have been blocked out as > well. > > > > Mike > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfriiUwiL6u2aXCVvC6=A=2Evbt_EYPC8gBX%2B4%2BTiU%2Bx1w>