From owner-freebsd-arch@freebsd.org Sun Dec 31 15:03:14 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49169EB8AA1 for ; Sun, 31 Dec 2017 15:03:14 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1186176195 for ; Sun, 31 Dec 2017 15:03:13 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBVF3DqQ040555 for ; Sun, 31 Dec 2017 09:03:13 -0600 (CST) (envelope-from karels@FreeBSD.org) Message-Id: <201712311503.vBVF3DqQ040555@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Reply-to: karels@FreeBSD.org Subject: Re: making SW_WATCHDOG dynamic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <40553.1514732593.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Dec 2017 09:03:13 -0600 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 15:03:14 -0000 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