From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753518AbbFIIFo (ORCPT ); Tue, 9 Jun 2015 04:05:44 -0400 Received: from [208.91.199.152] ([208.91.199.152]:49112 "EHLO bh-25.webhostbox.net" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753566AbbFIIFd (ORCPT ); Tue, 9 Jun 2015 04:05:33 -0400 Message-ID: <55769E0E.8060801@roeck-us.net> Date: Tue, 09 Jun 2015 01:04:30 -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: Fu Wei CC: Timur Tabi , 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 , Catalin Marinas , Will Deacon , rjw@rjwysocki.net Subject: Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver References: <=fu.wei@linaro.org> <1433217907-928-1-git-send-email-fu.wei@linaro.org> <1433217907-928-6-git-send-email-fu.wei@linaro.org> <556DCC95.806@codeaurora.org> <556DE2D5.3090906@roeck-us.net> <5575DE48.8010308@roeck-us.net> <55766D74.2060401@roeck-us.net> In-Reply-To: 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=0.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 06/08/2015 11:37 PM, Fu Wei wrote: > > I would like to stress that pretimeout == 0 should not happen in a > real server system, that is why we defined a SBSA watchdog, but not > a normal one Clarification - In _your opinion_, a server should always use pretimeout. > But we still need to thinking about the situation that administrator > want to do this on a very special purpose. > I could as well argue that setting pretimeout is the special situation. Some administrators may not want to bother but just want the system to reset if a watchdog timeout occurs. _Maybe_ if it happens multiple times, they might want to set up pretimeout to figure out why. Declaring that one _has_ to configure pretimeout is just a personal opinion, nothing else. We don't know what server administrators want, and we should not dictate anything unless technically necessary. > maybe we can set min_pretimeout = 1 for this driver. that is just a suggestion. > No. It is not technically necessary. > >> if it must be set to a value > 0 I don't understand why >> setting it to 1 (instead of 1 second) would not be sufficient. > > it don't have to be 1 second , it can be 0.1, 0.5 or 0.01 second. like > I said before, we just need a time slot to setup WCV in > sbsa_gwdt_start. I have commented this in sbsa_gwdt_set_pretimeout in > this patchset. I think what you really want to say is that you want to have time to handle the interrupt. But handling the interrupt is not asked for if pretimeout == 0. > But I think the minimum time slot depend on implementation, the spec > doesn't mention about this. Yes, because a minimum value does not exist. > If pretimeout == 0, and we set up WOR a little bigger, it *ONLY* > affect "the worst case" I mention above. in this case, a administrator > set up pretimeout == 0 which should not happen in a real server, then > the system goes very wrong. I don't think it is important that this > server system reset in 1 second or 0.0001 second, at this time, this > server can not provide any useful info anyway(because we don't use > pretimeout). > If system may go wrong, the administrator should set up pretimeout > > 0 to figure out what is wrong with it just like he always should do. > Yes, exactly. But otherwise, if pretimeout is set to 0, we want to reset immediately as directed. As I interpret the specification, WOR=0 forces WS1 immediately after WS0. 1) if TimeoutRefresh = True: CompareValue := SystemCounter + WOR (= SystemCounter WS0 := True 2) TimeoutRefresh is True again, WS0 == True: WS1 = True This is exactly the behavior we want if pretimeout == 0. In this situation, we don't want to handle the interrupt, we just want to reset the system as fast as possible. Having said that, have you tested what happens in your system if you set WOR=0 ? Thanks, Guenter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Date: Tue, 09 Jun 2015 01:04:30 -0700 Message-ID: <55769E0E.8060801@roeck-us.net> References: <=fu.wei@linaro.org> <1433217907-928-1-git-send-email-fu.wei@linaro.org> <1433217907-928-6-git-send-email-fu.wei@linaro.org> <556DCC95.806@codeaurora.org> <556DE2D5.3090906@roeck-us.net> <5575DE48.8010308@roeck-us.net> <55766D74.2060401@roeck-us.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-watchdog-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Fu Wei Cc: Timur Tabi , 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 , Catalin Marinas , Will Deacon , rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org List-Id: devicetree@vger.kernel.org On 06/08/2015 11:37 PM, Fu Wei wrote: > > I would like to stress that pretimeout == 0 should not happen in a > real server system, that is why we defined a SBSA watchdog, but not > a normal one Clarification - In _your opinion_, a server should always use pretimeout. > But we still need to thinking about the situation that administrator > want to do this on a very special purpose. > I could as well argue that setting pretimeout is the special situation. Some administrators may not want to bother but just want the system to reset if a watchdog timeout occurs. _Maybe_ if it happens multiple times, they might want to set up pretimeout to figure out why. Declaring that one _has_ to configure pretimeout is just a personal opinion, nothing else. We don't know what server administrators want, and we should not dictate anything unless technically necessary. > maybe we can set min_pretimeout = 1 for this driver. that is just a suggestion. > No. It is not technically necessary. > >> if it must be set to a value > 0 I don't understand why >> setting it to 1 (instead of 1 second) would not be sufficient. > > it don't have to be 1 second , it can be 0.1, 0.5 or 0.01 second. like > I said before, we just need a time slot to setup WCV in > sbsa_gwdt_start. I have commented this in sbsa_gwdt_set_pretimeout in > this patchset. I think what you really want to say is that you want to have time to handle the interrupt. But handling the interrupt is not asked for if pretimeout == 0. > But I think the minimum time slot depend on implementation, the spec > doesn't mention about this. Yes, because a minimum value does not exist. > If pretimeout == 0, and we set up WOR a little bigger, it *ONLY* > affect "the worst case" I mention above. in this case, a administrator > set up pretimeout == 0 which should not happen in a real server, then > the system goes very wrong. I don't think it is important that this > server system reset in 1 second or 0.0001 second, at this time, this > server can not provide any useful info anyway(because we don't use > pretimeout). > If system may go wrong, the administrator should set up pretimeout > > 0 to figure out what is wrong with it just like he always should do. > Yes, exactly. But otherwise, if pretimeout is set to 0, we want to reset immediately as directed. As I interpret the specification, WOR=0 forces WS1 immediately after WS0. 1) if TimeoutRefresh = True: CompareValue := SystemCounter + WOR (= SystemCounter WS0 := True 2) TimeoutRefresh is True again, WS0 == True: WS1 = True This is exactly the behavior we want if pretimeout == 0. In this situation, we don't want to handle the interrupt, we just want to reset the system as fast as possible. Having said that, have you tested what happens in your system if you set WOR=0 ? 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