From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>,
mingo@elte.hu, peterz@infradead.org, aris@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [watchdog] combine nmi_watchdog and softlockup
Date: Fri, 9 Apr 2010 18:56:50 +0400 [thread overview]
Message-ID: <20100409145650.GA5602@lenovo> (raw)
In-Reply-To: <20100409000036.GC6672@nowhere>
On Fri, Apr 09, 2010 at 02:00:38AM +0200, Frederic Weisbecker wrote:
> On Tue, Apr 06, 2010 at 07:31:15PM +0400, Cyrill Gorcunov wrote:
> > > I fear the cpu clock is not going to help you detecting any hard lockups.
> > > If you're stuck in an interrupt or an irq disabled loop, your cpu clock is
> > > not going to fire.
> > >
> >
> > I guess it's not supposed to. For such cases only nmi irqs may help for which
> > the perf events are there (/me need to check if we program apic timer for anything
> > like that). But it should help for other deadlocks. Or I miss something?
>
>
> Actually not. What the hardlockup detector does it to check the progression
> of irqs.
>
yup, i know what nmi-watchdog is doing. I guess you've misunderstood me. I meant
that sw-driven detector is not supposed to guard against the cases you're
referring to. I don't remember the details but someone proposed to make a
fallback to sw-watchdog if there is no ability to use nmi from perf-events
(for any reason) which eventually being implemented in Don's patch. And
there will be a message that watchdog has been switched to sw-driven
scaffold. So user will (or should) see this message and mark it I believe.
This sw-watchdog is like "ok, we've been trying our best but there is a
problem and the only solution we could offer -- is to use sw-watchdog".
That is how I understand the reason for sw-watchdog there.
>
> So it detects true hardlockups: stuck in an irq disabled section.
> If you don't have NMI to detect that (here this made by hardware clock based
> on cpu cycles overflows), then you're screwed. The hardlockup detector is
> useless with a maskable irq based clock.
>
-- Cyrill
next prev parent reply other threads:[~2010-04-09 14:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 21:33 [watchdog] combine nmi_watchdog and softlockup Don Zickus
2010-03-28 2:46 ` Aristeu Sergio Rozanski Filho
2010-03-29 18:26 ` Don Zickus
2010-03-30 14:52 ` Aristeu Sergio Rozanski Filho
2010-04-05 20:11 ` Cyrill Gorcunov
2010-04-05 20:16 ` Don Zickus
2010-04-05 14:11 ` Don Zickus
2010-04-09 1:02 ` Frederic Weisbecker
2010-04-09 13:32 ` Don Zickus
2010-04-06 14:13 ` Frederic Weisbecker
2010-04-06 15:31 ` Cyrill Gorcunov
2010-04-08 23:52 ` Frederic Weisbecker
2010-04-09 0:00 ` Frederic Weisbecker
2010-04-09 14:56 ` Cyrill Gorcunov [this message]
2010-04-09 15:05 ` Don Zickus
2010-04-06 18:59 ` Don Zickus
2010-04-09 0:22 ` Frederic Weisbecker
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=20100409145650.GA5602@lenovo \
--to=gorcunov@gmail.com \
--cc=aris@redhat.com \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@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