[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0707252113020.21378@asgard.lang.hm>
Date: Wed, 25 Jul 2007 21:14:13 -0700 (PDT)
From: david@...g.hm
To: Len Brown <lenb@...nel.org>
cc: Al Boldi <a1426z@...ab.com>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote:
> On Wednesday 25 July 2007 16:40, Al Boldi wrote:
>> Linus Torvalds wrote:
>>> On Wed, 25 Jul 2007, Len Brown wrote:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
>>>> release
>>>>
>>>> Fixes regressions -- a build failure, an oops, some dmesg spam.
>>>> Also fixes some D-state issues and adds ACPI module auto-loading.
>>>> Yes, I'd hoped to get the last two in before rc1.
>>>> I'm hopeful that a couple-days into rc2 is sufficiently early for them.
>>>
>>> I hate pulling this, but I did. However, what I hate even more after
>>> having done so is that ACPI now seems to select CPU hotplug. Why?
>>>
>>> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
>>> hotplug,
>>
>> You are kidding, right? CPU hotplug is broken big time; it kills a machine
>> like virus-scanner. I always turn it of as a rule. And now you want
>> STR/STD to be dependent on it? Even on UP? Why?
>
> CPU_HOTPLUG is needed to take the non-boot processors off-line before the suspend,
> and to bring them on-line upon the resume. If you have specific problems
> with bringing logical processors offline and online, then please speak up
> because many are depending on this functionality working.
nobody is arguing that CPU_HOTPLUG should not be a requirement for
suspend, what we are questioning is why simply enabling ACPI should
require CPU_HOTPLUG.
not everyone who configures ACPI wants to use suspend (of any flavor)
David Lang
-
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