From: Shriram Rajagopalan <rshriram@gmail.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: stable@kernel.org, xen-devel@lists.xensource.com,
Ian Campbell <ian.campbell@citrix.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xen: ensure timer tick is resumed even on CPU driving the resume
Date: Thu, 20 May 2010 10:42:44 -0700 [thread overview]
Message-ID: <AANLkTimc7ErLqUi4VKRztjAi6TNrv0Ooarc20OjFolkc@mail.gmail.com> (raw)
In-Reply-To: <4BF427AB.4080301@goop.org>
[-- Attachment #1.1: Type: text/plain, Size: 2270 bytes --]
I know this is a long shot but is there an equivalent piece of code in the
2.6.18.8-xen kernel where this patch could be applied ? Assuming that the
2.6.18 also has a similar bug.
On Wed, May 19, 2010 at 11:02 AM, Jeremy Fitzhardinge <jeremy@goop.org>wrote:
> On 05/19/2010 08:36 AM, Ian Campbell wrote:
> > The core suspend/resume code is run from stop_machine on CPU0 but
> > parts of the suspend/resume machinery (including xen_arch_resume) are
> > run on whichever CPU happened to schedule the xenwatch kernel thread.
> >
> > As part of the non-core resume code xen_arch_resume is called in order
> > to restart the timer tick on non-boot processors. The boot processor
> > itself is taken care of by core timekeeping code.
> >
> > xen_arch_resume uses smp_call_function which does not call the given
> > function on the current processor. This means that we can end up with
> > one CPU not receiving timer ticks if the xenwatch thread happened to
> > be scheduled on CPU > 0.
> >
> > Use on_each_cpu instead of smp_call_function to ensure the timer tick
> > is resumed everywhere.
> >
>
> Argh, that seems to be a pretty common trap to fall into. Looks OK (but
> unfortunately doesn't fix my other problem).
>
> Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>
> J
>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> > Cc: Stable Kernel <stable@kernel.org>
> > ---
> > arch/x86/xen/suspend.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> > index 987267f..a9c6611 100644
> > --- a/arch/x86/xen/suspend.c
> > +++ b/arch/x86/xen/suspend.c
> > @@ -60,6 +60,6 @@ static void xen_vcpu_notify_restore(void *data)
> >
> > void xen_arch_resume(void)
> > {
> > - smp_call_function(xen_vcpu_notify_restore,
> > - (void *)CLOCK_EVT_NOTIFY_RESUME, 1);
> > + on_each_cpu(xen_vcpu_notify_restore,
> > + (void *)CLOCK_EVT_NOTIFY_RESUME, 1);
> > }
> >
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
--
perception is but an offspring of its own self
[-- Attachment #1.2: Type: text/html, Size: 3235 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-05-20 17:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1274283134.14939.205.camel@zakaz.uk.xensource.com>
2010-05-19 15:36 ` [PATCH] xen: ensure timer tick is resumed even on CPU driving the resume Ian Campbell
2010-05-19 18:02 ` [Xen-devel] " Jeremy Fitzhardinge
2010-05-20 17:42 ` Shriram Rajagopalan [this message]
2010-05-20 18:14 ` Jeremy Fitzhardinge
2010-06-03 8:44 [GIT 0/2] fixes for Xen live migration Ian Campbell
2010-06-03 8:44 ` [PATCH] xen: ensure timer tick is resumed even on CPU driving the resume Ian Campbell
-- strict thread matches above, loose matches on Subject: below --
2010-05-19 15:35 [GIT PULL] xen suspend resume fix Ian Campbell
2010-05-19 15:55 ` [PATCH] xen: ensure timer tick is resumed even on CPU driving the resume Ian Campbell
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=AANLkTimc7ErLqUi4VKRztjAi6TNrv0Ooarc20OjFolkc@mail.gmail.com \
--to=rshriram@gmail.com \
--cc=ian.campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--cc=xen-devel@lists.xensource.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;
as well as URLs for NNTP newsgroup(s).