From: panand@redhat.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range
Date: Thu, 5 May 2016 23:50:31 +0530 [thread overview]
Message-ID: <20160505182031.GB12434@dhcppc6.redhat.com> (raw)
In-Reply-To: <20160505164300.GA16914@roeck-us.net>
+kexec list
Hi Guenter,
On 05/05/2016:09:43:00 AM, Guenter Roeck wrote:
> On Wed, May 04, 2016 at 11:17:29AM -0500, Timur Tabi wrote:
> > 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.
> >
> I don't even understand how kexec-tools is involved in the first place.
> kexec-tools sounds like user space, which should execute _after_ the kernel
So _after_ the 1st kernel and _before_ the second kernel. It is an application
for the 1st kernel, which creates a tiny boot loader for 2nd kernel. After the
1st kernel is loaded, kexec-tools is executed in user space, which provides a
sane 2nd kernel and initramfs to the kernel using kexec() system call. Now 1st
kernel keep these information loaded into a specific memory called "Crash
Kernel" memory. When 1st kernel crashes, kernel kexec code passes control to
kexec boot loader, which does sha verification of 2nd kernel and initramfs and
passes control to 2nd kernel.
> and its modules are loaded (assuming modules are loaded from initramfs).
> If kexec-tools can somehow ping the watchdog (presumably by writing into
> the HW directly), I don't understand why it doesn't simply load the watchdog
> driver instead and let the watchdog core handle the heartbeats.
Because that tiny boot loader (which called purgatory) does not have any
knowledge about driver.
>
> I am really missing something here. How can kexec-tools do anything before
> the kernel is loaded ?
So, if we _do_ _not_ go with the current version of patch, probably this could
be the only available option. However, Even when we would kick watchdog once in
kexec boot loader, we will have to make sure the 2nd kernel is light enough to
load watchdog module before timeout. I think, in the long run we must have SBSA
watchdog specification improvement to keep WOR as 64 bit.
~Pratyush
next prev parent reply other threads:[~2016-05-05 18:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-03 8:20 [PATCH RFC] Watchdog: sbsa_gwdt: Enhance timeout range Pratyush Anand
2016-05-03 12:12 ` Timur Tabi
2016-05-03 13:24 ` Pratyush Anand
2016-05-03 13:47 ` Guenter Roeck
2016-05-03 14:17 ` Pratyush Anand
2016-05-03 14:46 ` Guenter Roeck
2016-05-03 15:04 ` Timur Tabi
2016-05-03 13:29 ` Guenter Roeck
2016-05-03 14:38 ` Pratyush Anand
2016-05-03 15:07 ` Timur Tabi
2016-05-03 15:51 ` Pratyush Anand
2016-05-03 17:16 ` Guenter Roeck
2016-05-04 14:14 ` Pratyush Anand
2016-05-04 14:21 ` Timur Tabi
2016-05-04 15:59 ` Pratyush Anand
2016-05-04 16:17 ` Timur Tabi
2016-05-05 16:43 ` Guenter Roeck
2016-05-05 18:20 ` Pratyush Anand [this message]
2016-05-05 18:22 ` Timur Tabi
2016-05-05 23:36 ` Guenter Roeck
2016-05-05 23:38 ` Timur Tabi
2016-05-05 23:45 ` Timur Tabi
2016-05-06 0:18 ` Guenter Roeck
2016-05-05 23:51 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160505182031.GB12434@dhcppc6.redhat.com \
--to=panand@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).