[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <572A2099.4070901@codeaurora.org>
Date: Wed, 4 May 2016 11:17:29 -0500
From: Timur Tabi <timur@...eaurora.org>
To: Pratyush Anand <panand@...hat.com>
Cc: Guenter Roeck <linux@...ck-us.net>, fu.wei@...aro.org,
Suravee.Suthikulpanit@....com, wim@...ana.be,
linux-arm-kernel@...ts.infradead.org,
linux-watchdog@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>,
Dave Young <dyoung@...hat.com>,
Wim Van Sebroeck <wim@...ana.be>
Subject: Re: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range
Pratyush Anand wrote:
> Its unique to SBSA because you have very little timeout here. kexec-tools
> upstream does not have any mechanism to handle watchdog timeout. Lets say even
> if we implement a framework there, the best it can do is to ping the watchdog
> again.
Ok, so it's more accurate to say that kexec has a minimum watchdog
timeout requirement. What happens if the system admin sets the timeout
to 5 seconds arbitrarily? The system will reset during kexec, no matter
which hardware is used.
This still sounds like a band-aid to me. We're just assuming that we
need a timeout of at least 20 seconds to support kexec. Frankly, this
still sounds like a problem the kexec developers needs to acknowledge
and deal with.
Still I'm okay with a patch that extends the timeout by programming WCV,
but it has to be commented as a hack specifically to support kexec
because the timeout might be too short. Then Wim can decide whether he
supports such changes.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.
Powered by blists - more mailing lists