From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 23 20:14:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F3BEB687; Wed, 23 Jan 2013 20:14:50 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by mx1.freebsd.org (Postfix) with ESMTP id A68A0C28; Wed, 23 Jan 2013 20:14:50 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id h2so8916266oag.21 for ; Wed, 23 Jan 2013 12:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tD5eXihJNRkvfmzDh6+MSohTZo1h6Tf99obdWgrLxII=; b=soECJEEeCnDyBwJekV543XV+FVKnb8XJJiYuVnTTIopAsVb/4W1bYuy1ddSh3Bb7NM Ku4RCW8OXB5QJXRteWOAEaOOc5AEbp3ZLtv2yVBLhY+4gBvW/1jIS92h0Qykexd16SaE N/XW9m7W4Hys2CF3EhaFkCcgdBQvi5rZ5UyxoMhMsvyFhbVsOVyNzrtTLbvfFwP9IVFv fWqdDbycHTx/34knemKEwZfW+AM1Tg03teER5p7xgl4ZrqiT4Wwoy/plPzAc3qgYUONv ubjlrStXwbtgWbqeZNIiq+iXPYTzxE5C1jbTIQnt/8hqJEzgF0dJP2l0ngI8/w8l1BeI sMcw== MIME-Version: 1.0 X-Received: by 10.60.1.132 with SMTP id 4mr2038646oem.140.1358972084208; Wed, 23 Jan 2013 12:14:44 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.60.36.234 with HTTP; Wed, 23 Jan 2013 12:14:44 -0800 (PST) In-Reply-To: <1358960253.32417.467.camel@revolution.hippie.lan> References: <1358894455.17521.YahooMailClassic@web181706.mail.ne1.yahoo.com> <201301231025.41118.jhb@freebsd.org> <5100142D.7040904@freebsd.org> <1358960253.32417.467.camel@revolution.hippie.lan> Date: Wed, 23 Jan 2013 15:14:44 -0500 X-Google-Sender-Auth: cQv7l8XMJc1H8fhrn8I7PU5U2Ko Message-ID: Subject: Re: NMI watchdog functionality on Freebsd From: Ed Maste To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Sushanth Rai , mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 20:14:51 -0000 On 23 January 2013 11:57, Ian Lepore wrote: > > But adding a real hardware watchdog that fires on a slightly longer > timeout than the NMI watchdog gives you the best of everything: you get > information if it's possible to produce it, and you get a real hardware > reset shortly thereafter if producing the info fails. Yes, this is a great option if supported by hardware. Some Supermicro motherboards (like the X8STi) have two independent watchdogs, and one of them has a jumper to choose between NMI and reset upon expiry. In addition, the wbwd(4) driver has a sysctl to override the normal timeout to make the dual-stage watchdog possible: dev.wbwd.0.timeout_override This variable allows to program the timer to a value independent on the one provided by the watchdog(4) framework while still relying on the regular updates from e.g. watchdogd(8). This is particularly useful if your system provides multiple watchdogs and you want them to fire in a special sequence to trigger an NMI after a shorter period than the reset timeout for example. The value set must not be lower than the sleep time of watchdogd(8). A value of 0 disables this feature and the timeout value provided by watchdog(4) will be used. I hope this capability moves into the watchdog infrastructure rather than existing as a driver-specific kluge.