making SW_WATCHDOG dynamic

[Rodney W. Grimes]

> 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.


> 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org