All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Dave Young <dyoung@redhat.com>,
	wim@iguana.be, dzickus@redhat.com, bhe@redhat.com,
	linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] watchdog: add a parameter for stop wdt before register
Date: Wed, 15 Jan 2014 11:55:12 -0500	[thread overview]
Message-ID: <20140115165512.GD3180@redhat.com> (raw)
In-Reply-To: <20140115121556.0407a099@alan.etchedpixels.co.uk>

On Wed, Jan 15, 2014 at 12:15:56PM +0000, One Thousand Gnomes wrote:
> > watchdog and crash dump really conflicts to some degree, from the watchdog
> > point of view it can reboot system whhen kdump kernel hangs. But from kdump
> > point of view it want ensure saving the vmcore for later debugging.
> > 
> > Maybe we can only select only one in this case.
> 
> You want to be able to make a decision at runtime which to use.
> 
> > > - if it can be stopped, you can open and stop it
> > 
> > For the last one since crashing happens we have no chance to open and stop.
> 
> When you decide you need to set up to catch a core rather than just
> crash you can open and stop the watchdog (if supported), and you can then
> set up for a kdump and then at some point later if it crashes capture the
> dump.

Disabling watchdog if kdump serice starts will not make many happy. If
kernel hangs, we don't have a functionality to reboot it.

What about other idea of keeping watchdog interval long enough that new
kernel can boot, driver can load and then new driver/user space can
continue to kick the watchdog. And if second kernel hangs, watchdog will
reboot the system.

Thanks
Vivek

  reply	other threads:[~2014-01-15 16:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14  8:23 [PATCH] watchdog: add a parameter for stop wdt before register Dave Young
2014-01-14  8:26 ` Wim Van Sebroeck
2014-01-14  8:41   ` Dave Young
2014-01-14  9:44     ` Dave Young
2014-01-14 12:16 ` One Thousand Gnomes
2014-01-14 16:24   ` Vivek Goyal
2014-01-15  1:11     ` Dave Young
2014-01-15 16:46       ` Vivek Goyal
2014-01-16  1:50         ` Dave Young
2014-01-15  0:59   ` Dave Young
2014-01-15 12:15     ` One Thousand Gnomes
2014-01-15 16:55       ` Vivek Goyal [this message]
2014-01-16  1:52         ` Dave Young

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=20140115165512.GD3180@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=dzickus@redhat.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=wim@iguana.be \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.