On Wed, 7 Mar 2007 23:14:29 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

quoted text
> On Wednesday, 7 March 2007 22:16, Andrew Morton wrote:
> > On Wed, 7 Mar 2007 20:44:11 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > From: Rafael J. Wysocki <rjw@sisk.pl>
> > > 
> > > Prevent the WARN_ON() in arch/x86_64/kernel/acpi/sleep.c:init_low_mapping()
> > > from triggering by disabling nonboot CPUs before we finally enter the platform
> > > suspend.
> > > 
> > > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > > ---
> > >  kernel/power/disk.c |    1 +
> > >  kernel/power/user.c |    2 +-
> > >  2 files changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > Index: linux-2.6.21-rc2-mm2/kernel/power/disk.c
> > > ===================================================================
> > > --- linux-2.6.21-rc2-mm2.orig/kernel/power/disk.c
> > > +++ linux-2.6.21-rc2-mm2/kernel/power/disk.c
> > > @@ -61,6 +61,7 @@ static void power_down(suspend_disk_meth
> > >  	switch(mode) {
> > >  	case PM_DISK_PLATFORM:
> > >  		if (pm_ops && pm_ops->enter) {
> > > +			disable_nonboot_cpus();
> > >  			kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
> > >  			pm_ops->enter(PM_SUSPEND_DISK);
> > >  			break;
> > > Index: linux-2.6.21-rc2-mm2/kernel/power/user.c
> > > ===================================================================
> > > --- linux-2.6.21-rc2-mm2.orig/kernel/power/user.c
> > > +++ linux-2.6.21-rc2-mm2/kernel/power/user.c
> > > @@ -398,9 +398,9 @@ static int snapshot_ioctl(struct inode *
> > >  
> > >  		case PMOPS_ENTER:
> > >  			if (data->platform_suspend) {
> > > +				disable_nonboot_cpus();
> > >  				kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
> > >  				error = pm_ops->enter(PM_SUSPEND_DISK);
> > > -				error = 0;
> > >  			}
> > >  			break;
> > 
> > Is this considered 2.6.21 material?  If so why?
> 
> 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?

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/