[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0707280932470.3442@woody.linux-foundation.org>
Date: Sat, 28 Jul 2007 09:55:23 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Len Brown <lenb@...nel.org>
cc: "Rafael J. Wysocki" <rjw@...k.pl>, david@...g.hm,
Andrew Morton <akpm@...ux-foundation.org>,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
Pavel Machek <pavel@....cz>
Subject: Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for
2.6.23-rc1)
On Sat, 28 Jul 2007, Linus Torvalds wrote:
>
> And it's the *top*level* code that selects HOTPLUG_CPU. Through
> SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND.
In other words, the problem seems to be that
kernel/power/main.c:
suspend_devices_and_enter()
does the proper "disable/enable_nonboot_cpus()", but it does so without
having enabled CPU hotplug.
And you seem to think that it's ACPI that should enable the hotplug, even
though the code that actually needs it is _outside_ ACPI. And I think
that's wrong, and that this is a bug.
So I think the real issue is that we allow that
"suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in
the first place. It's not supposed to work that way.
Of course, it may well be that other architectures can happily suspend
even with multiple CPU's active, which may be the cause of this mess. But
I really think it shouldn't be ACPI that has to select the CPU hotplug,
since it's not ACPI that _uses_ it in the first place.
Rafael: making a config option for STR (the same way we have a config
option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU
seems to be the right thing. Len is right in that we do insane things
right now (trying to STR with multiple CPU's still active), and I just
don't think he's the one that should work around it!
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists