From: Don Zickus <dzickus@redhat.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Sameer Nanda <snanda@chromium.org>,
mingo@redhat.com, peterz@infradead.org, len.brown@intel.com,
pavel@ucw.cz, rjw@sisk.pl, akpm@linux-foundation.org,
msb@chromium.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, olofj@chromium.org
Subject: Re: [PATCH] watchdog: fix for lockup detector breakage on resume
Date: Mon, 30 Apr 2012 09:05:25 -0400 [thread overview]
Message-ID: <20120430130525.GM28185@redhat.com> (raw)
In-Reply-To: <4F9E2D3D.3000000@linux.vnet.ibm.com>
On Mon, Apr 30, 2012 at 11:42:13AM +0530, Srivatsa S. Bhat wrote:
> > +void lockup_detector_bootcpu_resume(void)
> > +{
> > + void *cpu = (void *)(long)smp_processor_id();
> > +
> > + /*
> > + * On the suspend/resume path the boot CPU does not go though the
> > + * offline->online transition. This breaks the NMI detector post
> > + * resume. Force an offline->online transition for the boot CPU on
> > + * resume.
> > + */
> > + cpu_callback(&cpu_nfb, CPU_DEAD, cpu);
> > + cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
> > +
>
>
> I have a couple of comments about this:
>
> 1. Strictly speaking, we should be using the _FROZEN variants here (since the
> tasks are still frozen).
>
> Like, cpu_callback(&cpu_nfb, CPU_DEAD_FROZEN, cpu);
> and cpu_callback(&cpu_nfb, CPU_ONLINE_FROZEN, cpu);
>
> Right now, since the same action is taken for either variant (ie., with or without
> _FROZEN), it really doesn't matter. But still, good to be on the safer side no?
>
> 2. Why are we skipping the CPU_UP_PREPARE_FROZEN callback?
>
> 3. How about hibernation? We don't hit this problem there?
Hi,
I have similar concerns as this patch seems kinda like a hack. OTOH I
don't know all the available hooks for the suspend/resume paths. I would
have assumed there was a special case call for the boot cpu to shutdown or
at least disable its services. Wouldn't a lot of other tasks run into
similar problems as the watchdog? I don't think the watchdog does
anything special that requires a special hook into the suspend path.
What do other hardware timers do on the suspend path?
Cheers,
Don
next prev parent reply other threads:[~2012-04-30 13:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 18:10 [PATCH] watchdog: fix for lockup detector breakage on resume Sameer Nanda
2012-04-27 21:12 ` Andrew Morton
2012-04-27 21:33 ` Rafael J. Wysocki
2012-04-27 21:40 ` Sameer Nanda
2012-04-27 22:03 ` Andrew Morton
2012-04-27 22:20 ` Sameer Nanda
2012-04-30 6:12 ` Srivatsa S. Bhat
2012-04-30 13:05 ` Don Zickus [this message]
2012-04-30 21:10 ` Sameer Nanda
2012-05-01 17:25 ` Sameer Nanda
2012-05-02 13:14 ` Srivatsa S. Bhat
2012-05-01 17:22 ` [PATCH v2] " Sameer Nanda
2012-05-07 3:24 ` Anshuman Khandual
2012-06-08 21:44 ` Andrew Morton
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=20120430130525.GM28185@redhat.com \
--to=dzickus@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=msb@chromium.org \
--cc=olofj@chromium.org \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=snanda@chromium.org \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
/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