From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Dave Jones <davej@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>,
Shaohua Li <shaohua.li@intel.com>
Subject: Re: [PATCH] swsusp: Disable nonboot CPUs before entering platform suspend
Date: Thu, 8 Mar 2007 01:48:35 +0100 [thread overview]
Message-ID: <200703080148.35962.rjw@sisk.pl> (raw)
In-Reply-To: <20070308002024.GF31910@redhat.com>
On Thursday, 8 March 2007 01:20, Dave Jones wrote:
> On Thu, Mar 08, 2007 at 12:13:05AM +0100, Rafael J. Wysocki wrote:
>
> > > > Well, the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> > > > triggers every time an SMP x86_64 box is suspended to disk using the platform
> > > > mode (default), which is quite annoying IMHO and users think something wrong is
> > > > going on. This will probably cause them to report the problem and I'd rather
> > > > like to avoid handling these reports. ;-)
> > >
> > > Well sure - if patches were always error-free, we'd always apply them
> > > immediately.
> > >
> > > The question is: is the risk of this patch breaking things exceeded by the
> > > benefit which you describe?
> >
> > Well, it has survived some testing (http://lkml.org/lkml/2007/3/7/16). Also,
> > before the code ordering in 2.6.21-rc* we had been running on one CPU
> > here, so I think the risk is small.
> >
> > We could remove the WARN_ON() as Pavel has just suggested, but first I'd like
> > to know who put it there and why.
>
> It was introduced as part of ..
>
> commit 55b2355eefc2f160246226d4d69fed431173a4d5
> Author: Shaohua Li <shaohua.li@intel.com>
> Date: Fri Jun 23 02:04:49 2006 -0700
>
> [PATCH] don't use flush_tlb_all in suspend time
>
> flush_tlb_all uses on_each_cpu, which will disable/enable interrupt.
> In suspend/resume time, this will make interrupt wrongly enabled.
Ah, thanks.
So the question is what can go wrong if we ignore the TLBs of the other
CPUs that may be on-line when init_low_mapping() is executed.
Frankly, I don't know.
next prev parent reply other threads:[~2007-03-08 0:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-07 19:44 Rafael J. Wysocki
2007-03-07 21:07 ` Pavel Machek
2007-03-09 7:58 ` Rafael J. Wysocki
2007-03-09 8:54 ` Pavel Machek
2007-03-09 20:07 ` Rafael J. Wysocki
2007-03-09 21:07 ` Pavel Machek
2007-03-09 21:24 ` Rafael J. Wysocki
2007-03-09 22:13 ` Pavel Machek
2007-03-09 22:34 ` Rafael J. Wysocki
2007-03-09 22:48 ` Pavel Machek
2007-03-09 12:29 ` Heiko Carstens
2007-03-09 19:39 ` Rafael J. Wysocki
2007-03-09 22:10 ` Pavel Machek
2007-03-07 21:16 ` Andrew Morton
2007-03-07 22:14 ` Rafael J. Wysocki
2007-03-07 22:19 ` Pavel Machek
2007-03-07 23:14 ` Rafael J. Wysocki
2007-03-07 22:49 ` Andrew Morton
2007-03-07 23:13 ` Rafael J. Wysocki
2007-03-08 0:20 ` Dave Jones
2007-03-08 0:48 ` Rafael J. Wysocki [this message]
2007-03-09 1:11 ` Len Brown
2007-03-09 7:11 ` Rafael J. Wysocki
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=200703080148.35962.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=shaohua.li@intel.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
Powered by JetHome