Date: Sun, 31 Dec 2017 09:03:13 -0600 From: Mike Karels <karels@FreeBSD.org> To: freebsd-arch@freebsd.org Subject: Re: making SW_WATCHDOG dynamic Message-ID: <201712311503.vBVF3DqQ040555@mail.karels.net>
next in thread | raw e-mail | index | archive | help
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. I updated NOTES and the watchdog(4) information accordingly. 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 wou= ld be much apprectiated. I tested by enabling watchdogd with default paramet= ers, doing b"killall -STOP watchdogd", and then observing that the system dropp= ed 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 f= or 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712311503.vBVF3DqQ040555>