From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932497AbbEWUCI (ORCPT ); Sat, 23 May 2015 16:02:08 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:49032 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932279AbbEWUCE (ORCPT ); Sat, 23 May 2015 16:02:04 -0400 Message-ID: <5560DCB6.3090008@roeck-us.net> Date: Sat, 23 May 2015 13:01:58 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Timur Tabi , Fu Wei CC: Suravee Suthikulpanit , Linaro ACPI Mailman List , linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Wei Fu , G Gregory , Al Stone , Hanjun Guo , Ashwin Chaugule , Arnd Bergmann , vgandhi@codeaurora.org, wim@iguana.be, Jon Masters , Leo Duran , Jon Corbet , Mark Rutland Subject: Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver References: <=fu.wei@linaro.org> <1432197156-16947-1-git-send-email-fu.wei@linaro.org> <1432197156-16947-7-git-send-email-fu.wei@linaro.org> <555DFCD4.3040701@codeaurora.org> <5560D7AC.50009@codeaurora.org> In-Reply-To: <5560D7AC.50009@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/23/2015 12:40 PM, Timur Tabi wrote: [ ... ] > > I use emergency_restart(), because the watchdog-api.txt documentation says this: > > "If userspace fails (RAM error, kernel bug, whatever), the > notifications cease to occur, and the hardware watchdog will reset the > system (causing a reboot) after the timeout occurs." > > Maybe I'm reading this too literally, but to me this means that when the timeout expires, the system has to reset immediately. > > However, maybe panic() is better, since it can do the same thing and more. > I have a specific requirement at work to have watchdog expiration (not this watchdog, this is different HW) result in a panic, specifically to enable crashdump support and thus post-mortem analysis. I had not thought about this use case myself, and I had always wondered why watchdog driver implementers would choose to call panic() after an interrupt or NMI. But we live and learn, so now I finally understand. In the pretimeout/timeout world, the pretimeout would (typically) result in a panic, and the timeout would result in a reset. So one would set the timer register to 10s for 10s pretimeout and 20s timeout. However, the pretimeout concept assumes that there are two timers which can be set independently. As you had pointed out earlier, and as the specification seems to confirm, that is not the case here. As such, I don't really understand why and how the pretimeout / timeout concept would add any value here and not just make things more complicated than necessary. Maybe I am just missing something. Thanks, Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver Date: Sat, 23 May 2015 13:01:58 -0700 Message-ID: <5560DCB6.3090008@roeck-us.net> References: <=fu.wei@linaro.org> <1432197156-16947-1-git-send-email-fu.wei@linaro.org> <1432197156-16947-7-git-send-email-fu.wei@linaro.org> <555DFCD4.3040701@codeaurora.org> <5560D7AC.50009@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5560D7AC.50009-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> Sender: linux-watchdog-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Timur Tabi , Fu Wei Cc: Suravee Suthikulpanit , Linaro ACPI Mailman List , linux-watchdog-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wei Fu , G Gregory , Al Stone , Hanjun Guo , Ashwin Chaugule , Arnd Bergmann , vgandhi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org, Jon Masters , Leo Duran , Jon Corbet , Mark Rutland List-Id: devicetree@vger.kernel.org On 05/23/2015 12:40 PM, Timur Tabi wrote: [ ... ] > > I use emergency_restart(), because the watchdog-api.txt documentation says this: > > "If userspace fails (RAM error, kernel bug, whatever), the > notifications cease to occur, and the hardware watchdog will reset the > system (causing a reboot) after the timeout occurs." > > Maybe I'm reading this too literally, but to me this means that when the timeout expires, the system has to reset immediately. > > However, maybe panic() is better, since it can do the same thing and more. > I have a specific requirement at work to have watchdog expiration (not this watchdog, this is different HW) result in a panic, specifically to enable crashdump support and thus post-mortem analysis. I had not thought about this use case myself, and I had always wondered why watchdog driver implementers would choose to call panic() after an interrupt or NMI. But we live and learn, so now I finally understand. In the pretimeout/timeout world, the pretimeout would (typically) result in a panic, and the timeout would result in a reset. So one would set the timer register to 10s for 10s pretimeout and 20s timeout. However, the pretimeout concept assumes that there are two timers which can be set independently. As you had pointed out earlier, and as the specification seems to confirm, that is not the case here. As such, I don't really understand why and how the pretimeout / timeout concept would add any value here and not just make things more complicated than necessary. Maybe I am just missing something. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html