From owner-freebsd-arch@freebsd.org Mon Oct 17 08:20:09 2016 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 EC8B7C15E89 for ; Mon, 17 Oct 2016 08:20:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8631C1AE1 for ; Mon, 17 Oct 2016 08:20:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA18906 for ; Mon, 17 Oct 2016 11:20:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bw39S-000PC8-7C for freebsd-arch@FreeBSD.ORG; Mon, 17 Oct 2016 11:20:06 +0300 To: freebsd-arch@FreeBSD.org From: Andriy Gapon Subject: superio driver Message-ID: Date: Mon, 17 Oct 2016 11:19:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 08:20:10 -0000 I would like to add a driver for Super I/O chips: https://reviews.freebsd.org/D8175 In the review request you can find my rationale and description for the driver as well as some question about its design. At this point I am looking mostly for some help with the design, but any reviews of the current code are also appreciated. Thank you. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Wed Oct 19 11:10:47 2016 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 DD295C18649 for ; Wed, 19 Oct 2016 11:10:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE80E01; Wed, 19 Oct 2016 11:10:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29164; Wed, 19 Oct 2016 14:10:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bwola-00027Z-OW; Wed, 19 Oct 2016 14:10:38 +0300 To: freebsd-arch@FreeBSD.org From: Andriy Gapon Subject: watchdog end-user interface Message-ID: Date: Wed, 19 Oct 2016 14:09:42 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 11:10:48 -0000 I know that there are people thinking about improving our watchdog infrastructure. Maybe it's time to discuss some ideas in public. I would like to start with discussing the end-user, or rather administrative, interface to the watchdog system. watchdogd always had -t timeout option. Not a too long time ago it has also grown a handful of new options: --softtimeout --softtimeout-action action --pretimeout timeout --pretimeout-action action I want to question if those options really belong to watchdogd. When a watchdog timer expires that results in a system-wide action (like a system reset). To me, that implies that there should be a single system-wide configuration point. And I am not sure that the daemon is the best choice for it. Personally I would prefer a sysctl interface for the following reasons: - easier to change the configuration - easier to query current values - easier to signal that a value getting set may be different from a requested value In my opinion, watchdogd should only be concerned with running a check action and patting the dog(s). And, by extension, WDIOCPATPAT should not re-configure the timeout, it should just reload the timers. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Wed Oct 19 11:18:21 2016 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 24821C187FC for ; Wed, 19 Oct 2016 11:18:21 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E4B99262; Wed, 19 Oct 2016 11:18:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 664FD2738B; Wed, 19 Oct 2016 11:18:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u9JBII81021378; Wed, 19 Oct 2016 11:18:18 GMT (envelope-from phk@phk.freebsd.dk) To: Andriy Gapon cc: freebsd-arch@FreeBSD.org Subject: Re: watchdog end-user interface In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21376.1476875898.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2016 11:18:18 +0000 Message-ID: <21377.1476875898@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 11:18:21 -0000 -------- In message , Andriy Gapo= n wri tes: >I want to question if those options really belong to watchdogd. >When a watchdog timer expires that results in a system-wide action (like = a >system reset). To me, that implies that there should be a single system-= wide >configuration point. And I am not sure that the daemon is the best choic= e for it. The reason I originally put it in a daemon, was to have the watchdog implicitly test the kernels ability to schedule trivial processes. It used to be, and may still be so that, there are deadlocks where the kernel was twiddling its thumbs but userland did not progress. Typical triggers for this are disk-I/O errors, corrupt filesystems, memory overcommit etc. A kernel-only watchdog patter would not trigger in that case. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Wed Oct 19 11:21:44 2016 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 DE939C1894B for ; Wed, 19 Oct 2016 11:21:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E445908 for ; Wed, 19 Oct 2016 11:21:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29194; Wed, 19 Oct 2016 14:21:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bwowI-00028M-Ka; Wed, 19 Oct 2016 14:21:42 +0300 Subject: Re: watchdog end-user interface To: Poul-Henning Kamp References: <21377.1476875898@critter.freebsd.dk> Cc: freebsd-arch@FreeBSD.org From: Andriy Gapon Message-ID: Date: Wed, 19 Oct 2016 14:20:46 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <21377.1476875898@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 11:21:45 -0000 On 19/10/2016 14:18, Poul-Henning Kamp wrote: > -------- > In message , Andriy Gapon wri > tes: > >> I want to question if those options really belong to watchdogd. >> When a watchdog timer expires that results in a system-wide action (like a >> system reset). To me, that implies that there should be a single system-wide >> configuration point. And I am not sure that the daemon is the best choice for it. > > The reason I originally put it in a daemon, was to have the watchdog > implicitly test the kernels ability to schedule trivial processes. > > It used to be, and may still be so that, there are deadlocks where > the kernel was twiddling its thumbs but userland did not progress. > Typical triggers for this are disk-I/O errors, corrupt filesystems, > memory overcommit etc. > > A kernel-only watchdog patter would not trigger in that case. I addressed this further down my post. Just in case, I think that watchdogd should do the pat-pats as it does now. But that's different from setting the timeout. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Wed Oct 19 21:31:56 2016 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 719AEC1969A for ; Wed, 19 Oct 2016 21:31:56 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 64926D7; Wed, 19 Oct 2016 21:31:56 +0000 (UTC) (envelope-from bright@mu.org) Received: from AlfredMacbookAir.local (104-244-24-105.PUBLIC.monkeybrains.net [104.244.24.105]) by elvis.mu.org (Postfix) with ESMTPSA id 46FA9346DEA8; Wed, 19 Oct 2016 14:31:49 -0700 (PDT) Subject: Re: watchdog end-user interface To: Poul-Henning Kamp , Andriy Gapon References: <21377.1476875898@critter.freebsd.dk> Cc: freebsd-arch@FreeBSD.org From: Alfred Perlstein Message-ID: <126689b6-c44b-688f-faff-4a27d3bd29b8@mu.org> Date: Wed, 19 Oct 2016 14:31:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <21377.1476875898@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 21:31:56 -0000 On 10/19/16 4:18 AM, Poul-Henning Kamp wrote: > -------- > In message , Andriy Gapon wri > tes: > >> I want to question if those options really belong to watchdogd. >> When a watchdog timer expires that results in a system-wide action (like a >> system reset). To me, that implies that there should be a single system-wide >> configuration point. And I am not sure that the daemon is the best choice for it. > The reason I originally put it in a daemon, was to have the watchdog > implicitly test the kernels ability to schedule trivial processes. > > It used to be, and may still be so that, there are deadlocks where > the kernel was twiddling its thumbs but userland did not progress. > Typical triggers for this are disk-I/O errors, corrupt filesystems, > memory overcommit etc. > > A kernel-only watchdog patter would not trigger in that case. Exactly. -Alfred From owner-freebsd-arch@freebsd.org Wed Oct 19 21:32:30 2016 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 55FA3C196DB for ; Wed, 19 Oct 2016 21:32:30 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 498B71E1; Wed, 19 Oct 2016 21:32:30 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from AlfredMacbookAir.local (104-244-24-105.PUBLIC.monkeybrains.net [104.244.24.105]) by elvis.mu.org (Postfix) with ESMTPSA id 0B738346DE24; Wed, 19 Oct 2016 14:32:30 -0700 (PDT) Subject: Re: watchdog end-user interface To: Andriy Gapon , freebsd-arch@FreeBSD.org References: From: Alfred Perlstein Organization: FreeBSD Message-ID: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> Date: Wed, 19 Oct 2016 14:32:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 21:32:30 -0000 On 10/19/16 4:09 AM, Andriy Gapon wrote: > I know that there are people thinking about improving our watchdog > infrastructure. Maybe it's time to discuss some ideas in public. > > I would like to start with discussing the end-user, or rather administrative, > interface to the watchdog system. > > watchdogd always had -t timeout option. > Not a too long time ago it has also grown a handful of new options: > --softtimeout > --softtimeout-action action > --pretimeout timeout > --pretimeout-action action > > I want to question if those options really belong to watchdogd. > When a watchdog timer expires that results in a system-wide action (like a > system reset). To me, that implies that there should be a single system-wide > configuration point. And I am not sure that the daemon is the best choice for it. > > Personally I would prefer a sysctl interface for the following reasons: > - easier to change the configuration > - easier to query current values > - easier to signal that a value getting set may be different from a requested value > > In my opinion, watchdogd should only be concerned with running a check action > and patting the dog(s). And, by extension, WDIOCPATPAT should not re-configure > the timeout, it should just reload the timers. > Please look at the Linux interface for watchdogs, it is pretty good and could/should be ported to us. -Alfred From owner-freebsd-arch@freebsd.org Wed Oct 19 21:47:27 2016 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 0936CC19A0E for ; Wed, 19 Oct 2016 21:47:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 B9736BCE; Wed, 19 Oct 2016 21:47:26 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id m5so36056762qtb.3; Wed, 19 Oct 2016 14:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nu3EwRFxbnn5RgIH7QBMMq3eHfO+M0LDSHiCpBT9Lds=; b=oOXVbw4UqprN8m4yzpLo5s8ZHaTuZD1UQBFZOMIUN1DynR0T+MxxfbpKJPwNbIX7ji iESqXYvGhAfWPsIqstX1EI8GSdsim+2JTQC/IWJfYHrZhTPEM2y2YhiBhXxUXmXelQOw 6mI6AVdgkhWzm8DaciwQ/SdgunYFc9h2g4OEtgxwhq7hisnZn4PDwEWsP3AueBMex6Vd Ad7EJOmuWnGesXqOXhBmXE329IzU16XN11EntpFdP/quRPxM9nYKNn4ttEFZ8YjUj5GO GpOqlR3tQRQA+EJD2WceamZEoIFkv0ITqKLxsH6cEyuFrhQ5r0Mgk5h8eBoukOJmK8WE 9mMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nu3EwRFxbnn5RgIH7QBMMq3eHfO+M0LDSHiCpBT9Lds=; b=LdVPqZt34UHi6NjCvdHefFd5xuxxTQR0du/It/3dhv0hlmZIRujRiU80qF0byt7ZjI CpFBYPzPtucMS/OZ9jdcNQcucqqDeL5Oht37FndReZtLKhDz8jBtverrhyhSjXTxU9PG 8iLUUrOSQaSB1OwuZmkZPzD/ObxF+3M+czLFRjcTJkBbN7zRUKrsV5m00AX8NfN2ciAZ LiwZxW7dxLc7qtPGuaQewr+/GFbeA6sapR6ZfqnHf7ZjzPqi/9sU0XGtDyTpG4/DeYkL HxPy+CsF5HYdhRV+cpTxQFbTIVxnomxCreaWGaIGaDaaf41ueFi07z7mMT4QWXSM7iqy 0nYg== X-Gm-Message-State: AA6/9Rlk4siwqBqU9hvxvgikZ6TVgPxY9Mr3quvNfTPIpw08TU/QdTb6OvFM+WwOCtL9EUx5Nlj9qIMRVCoiTQ== X-Received: by 10.200.46.43 with SMTP id r40mr8720790qta.145.1476913645757; Wed, 19 Oct 2016 14:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.29.33 with HTTP; Wed, 19 Oct 2016 14:47:25 -0700 (PDT) In-Reply-To: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> References: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> From: Ngie Cooper Date: Wed, 19 Oct 2016 14:47:25 -0700 Message-ID: Subject: Re: watchdog end-user interface To: Alfred Perlstein Cc: Andriy Gapon , "freebsd-arch@FreeBSD.org Arch" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 21:47:27 -0000 On Wed, Oct 19, 2016 at 2:32 PM, Alfred Perlstein wrote: ... > Please look at the Linux interface for watchdogs, it is pretty good and > could/should be ported to us. We (Isilon) also have a software watchdog implementation (in lieu of IPMI+watchdogd) to make sure "userspace processes are making progress". It would be nice if there was a generalized software watchdog subsystem available in FreeBSD -- I think your suggestion to follow Linux's example may be a good investigative step to avoid reinventing the wheel too much. Thanks! -Ngie From owner-freebsd-arch@freebsd.org Thu Oct 20 07:08:20 2016 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 9449EC1AF31 for ; Thu, 20 Oct 2016 07:08:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4C2E7D; Thu, 20 Oct 2016 07:08:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA02997; Thu, 20 Oct 2016 10:08:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bx7Sb-0003Ex-BG; Thu, 20 Oct 2016 10:08:17 +0300 Subject: Re: watchdog end-user interface To: Alfred Perlstein , freebsd-arch@FreeBSD.org References: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> From: Andriy Gapon Message-ID: <78d70638-6117-cb8d-032a-c84fb52c9708@FreeBSD.org> Date: Thu, 20 Oct 2016 10:06:56 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 07:08:20 -0000 On 20/10/2016 00:32, Alfred Perlstein wrote: > > > On 10/19/16 4:09 AM, Andriy Gapon wrote: >> I know that there are people thinking about improving our watchdog >> infrastructure. Maybe it's time to discuss some ideas in public. >> >> I would like to start with discussing the end-user, or rather administrative, >> interface to the watchdog system. >> >> watchdogd always had -t timeout option. >> Not a too long time ago it has also grown a handful of new options: >> --softtimeout >> --softtimeout-action action >> --pretimeout timeout >> --pretimeout-action action >> >> I want to question if those options really belong to watchdogd. >> When a watchdog timer expires that results in a system-wide action (like a >> system reset). To me, that implies that there should be a single system-wide >> configuration point. And I am not sure that the daemon is the best choice for >> it. >> >> Personally I would prefer a sysctl interface for the following reasons: >> - easier to change the configuration >> - easier to query current values >> - easier to signal that a value getting set may be different from a requested >> value >> >> In my opinion, watchdogd should only be concerned with running a check action >> and patting the dog(s). And, by extension, WDIOCPATPAT should not re-configure >> the timeout, it should just reload the timers. >> > Please look at the Linux interface for watchdogs, it is pretty good and > could/should be ported to us. That's not what I actually wanted to discuss. Anyway, I had looked at it and I didn't find it a good model. I don't like that each watchdog driver creates its own device entry. I prefer the FreeBSD model where all drivers can work in concert. If the most popular Linux watchdog daemon is used, then you would need multiple instances of it (watchdog or wd_keepalive) to use multiple drivers. I don't like the seconds resolution. It should be enough for everybody and, hey, it's better than our power-of-two resolution in the most used range. But I think that we could be even better. I do not like this (typical of Linux, I'd say): The Linux watchdog API is a rather ad-hoc construction and different drivers implement different, and sometimes incompatible, parts of it. There can be different opinions and different people can work towards different goal. Personally, I do not have a goal of having Linux-like watchdog interface on FreeBSD. References: https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt https://www.kernel.org/doc/Documentation/watchdog/watchdog-kernel-api.txt http://linux.die.net/man/5/watchdog.conf https://sourceforge.net/p/watchdog/code/ci/master/tree/src/keep_alive.c?format=raw http://www.sat.dundee.ac.uk/psc/watchdog/Linux-Watchdog.html -- Andriy Gapon From owner-freebsd-arch@freebsd.org Thu Oct 20 07:15:33 2016 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 EAFB4C19116 for ; Thu, 20 Oct 2016 07:15:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E42C266 for ; Thu, 20 Oct 2016 07:15:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03011; Thu, 20 Oct 2016 10:15:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1bx7Zb-0003FM-Fx; Thu, 20 Oct 2016 10:15:31 +0300 Subject: Re: watchdog end-user interface To: Ngie Cooper References: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> Cc: freebsd-arch@FreeBSD.org From: Andriy Gapon Message-ID: Date: Thu, 20 Oct 2016 10:14:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 07:15:34 -0000 On 20/10/2016 00:47, Ngie Cooper wrote: > On Wed, Oct 19, 2016 at 2:32 PM, Alfred Perlstein wrote: > ... >> Please look at the Linux interface for watchdogs, it is pretty good and >> could/should be ported to us. > > We (Isilon) also have a software watchdog implementation (in lieu of > IPMI+watchdogd) to make sure "userspace processes are making > progress". Please tell me more about this. It seems that there could be different definitions of 'software watchdog' and different expectations of what it should do. For example, we have SW_WATCHDOG in the tree for ages. It's a watchdog driver that's driver by clock interrupts and its logic is implemented in software. In the current implementation there is only one timeout action - a panic. Not too long ago Alfred added another software watchdog that's driven by callout-s. To me it's quite alike to SW_WATCHDOG, but it has configurable timeout actions: printf, log, panic, debugger. So, I wonder how Isilon's software watchdog is different from the above two. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Thu Oct 20 07:30:20 2016 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 84A44C19589 for ; Thu, 20 Oct 2016 07:30:20 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 775049CE; Thu, 20 Oct 2016 07:30:20 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:6493:24e3:fa2:858f]) by elvis.mu.org (Postfix) with ESMTPSA id 8A687346DE24; Thu, 20 Oct 2016 00:30:19 -0700 (PDT) Subject: Re: watchdog end-user interface To: Andriy Gapon , freebsd-arch@FreeBSD.org References: <7a74df08-b5d9-5629-b71e-b577d8876e5d@freebsd.org> <78d70638-6117-cb8d-032a-c84fb52c9708@FreeBSD.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <35f650cf-96ca-f3a8-0ee3-54a34dc95737@freebsd.org> Date: Thu, 20 Oct 2016 00:30:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <78d70638-6117-cb8d-032a-c84fb52c9708@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 07:30:20 -0000 On 10/20/16 12:06 AM, Andriy Gapon wrote: > On 20/10/2016 00:32, Alfred Perlstein wrote: >> >> On 10/19/16 4:09 AM, Andriy Gapon wrote: >>> I know that there are people thinking about improving our watchdog >>> infrastructure. Maybe it's time to discuss some ideas in public. >>> >>> I would like to start with discussing the end-user, or rather administrative, >>> interface to the watchdog system. >>> >>> watchdogd always had -t timeout option. >>> Not a too long time ago it has also grown a handful of new options: >>> --softtimeout >>> --softtimeout-action action >>> --pretimeout timeout >>> --pretimeout-action action >>> >>> I want to question if those options really belong to watchdogd. >>> When a watchdog timer expires that results in a system-wide action (like a >>> system reset). To me, that implies that there should be a single system-wide >>> configuration point. And I am not sure that the daemon is the best choice for >>> it. >>> >>> Personally I would prefer a sysctl interface for the following reasons: >>> - easier to change the configuration >>> - easier to query current values >>> - easier to signal that a value getting set may be different from a requested >>> value >>> >>> In my opinion, watchdogd should only be concerned with running a check action >>> and patting the dog(s). And, by extension, WDIOCPATPAT should not re-configure >>> the timeout, it should just reload the timers. >>> >> Please look at the Linux interface for watchdogs, it is pretty good and >> could/should be ported to us. > That's not what I actually wanted to discuss. > > Anyway, I had looked at it and I didn't find it a good model. > > I don't like that each watchdog driver creates its own device entry. > I prefer the FreeBSD model where all drivers can work in concert. > If the most popular Linux watchdog daemon is used, then you would need multiple > instances of it (watchdog or wd_keepalive) to use multiple drivers. > > I don't like the seconds resolution. It should be enough for everybody and, > hey, it's better than our power-of-two resolution in the most used range. > But I think that we could be even better. > > I do not like this (typical of Linux, I'd say): > The Linux watchdog API is a rather ad-hoc construction and different > drivers implement different, and sometimes incompatible, parts of it. > > There can be different opinions and different people can work towards different > goal. Personally, I do not have a goal of having Linux-like watchdog interface > on FreeBSD. > > References: > https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt > https://www.kernel.org/doc/Documentation/watchdog/watchdog-kernel-api.txt > http://linux.die.net/man/5/watchdog.conf > https://sourceforge.net/p/watchdog/code/ci/master/tree/src/keep_alive.c?format=raw > http://www.sat.dundee.ac.uk/psc/watchdog/Linux-Watchdog.html ¯\_(ツ)_/¯