From owner-freebsd-arch@freebsd.org Sun Dec 31 22:52:22 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 D9E15EABD0D for ; Sun, 31 Dec 2017 22:52:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A83CE6814D for ; Sun, 31 Dec 2017 22:52:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id b5so35584682itc.3 for ; Sun, 31 Dec 2017 14:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cArmbUE407r5V1zBuui/zA2yfXUajir0jlTYxEnO8W8=; b=H7dxY1wb81OFYEQrIQwieDQnx3CzTAzZKIc4qAJH5n0YE/FeHh3L5BFDCDYPcGRTSw IAKyYyZQ86SJF1s1K27EjMZaDxtiMgMELeOxGilZ378ZaYMmQ8Nl10E/MIcMvzmq9ig0 dQyrcPgnj3pCPagWwGv913jXBxdhGFs0IkdvN32piw0C124saLsj8ys/4vx1UvwP9JZ+ M94Z5H/c9zXLi3yi0RfylBombjPB0uYMPuRo4zjaIcvq7cD2+j56HNcpul7Iu/ZlGl+q IVEu7rklV9vnIv9pIvJ3OuuL8RY30l2Cp6Rzos59/hNjS3Fld/pKtIRSt5wKfQWsyt5c C96Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cArmbUE407r5V1zBuui/zA2yfXUajir0jlTYxEnO8W8=; b=B4vJ7daAdQEuJPFLsLw1BrI6JMxkTZyX82YlzIZABt1241V/UsINIL5QkXXW2EPqHo C32ZVhAdgoDKpEC1CTGXHbPgL/cvX+TLacMuPLe63OwQHYwhqv8a0cD58sefRC4YXshy lq66TKdnJRFalzLCOStX/x94LUytoLmTFnW+p5mL2AfhDC7qJFXbf1esCetXSXfOhsEc qqmJp3PKPNuAV0bSqRK7Go5DSqvBiIteAJWYe7aD4rrQQ3ddafq/8IPX7r9m0l9jgZ6K suqbV0Sn4h4pJ2ubJLoqkdTDWJQWJtVimVHVIwSY6QGTsTq0REpAlUlOg+66Qz1N9wEY 1/Ww== X-Gm-Message-State: AKGB3mKinBhZjewwuN0DD2R1287ykyXKEUAPP0R78YQqpgeQ3WWD78ve ZWy9NvyBNln9jrAgIW0yLkJ+00A0c4N4l7xK+EP//A== X-Google-Smtp-Source: ACJfBov7r01uvipcInmdIE9iQIBLiYMkhfZHXswL0dt3DENRUKFugWrpN0aP0wBqU8e7xPQ8gG0g+A6Mx0k76tCjOYM= X-Received: by 10.36.133.135 with SMTP id r129mr57713960itd.69.1514760741836; Sun, 31 Dec 2017 14:52:21 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 31 Dec 2017 14:52:20 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> References: <201712311503.vBVF3DqQ040555@mail.karels.net> <201712311801.vBVI1eCP082420@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Sun, 31 Dec 2017 15:52:20 -0700 X-Google-Sender-Auth: LHT6ATjvcC-wBXGDKfQWHcSE9QE Message-ID: Subject: Re: making SW_WATCHDOG dynamic To: "Rodney W. Grimes" Cc: karels@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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 22:52:22 -0000 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" >