On Mon 2007-07-30 21:09:33, [EMAIL PROTECTED] wrote:
> On Mon, 30 Jul 2007, Len Brown wrote:
>
> >On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
> >
> >>So I think the real issue is that we allow that
> >>"suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in
> >>the
On Mon 2007-07-30 21:09:33, [EMAIL PROTECTED] wrote:
On Mon, 30 Jul 2007, Len Brown wrote:
On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
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
On Mon, 30 Jul 2007, Len Brown wrote:
On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
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.
I don't see how
On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
> 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.
I don't see how CONFIG_HOTPLUG_CPU justifies its own
On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
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.
I don't see how CONFIG_HOTPLUG_CPU justifies its own existence.
On Mon, 30 Jul 2007, Len Brown wrote:
On Saturday 28 July 2007 12:55, Linus Torvalds wrote:
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.
I don't see how
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote:
>
> OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require
> quite a bit of (compilation) testing on different architectures.
Sure. I'm not too worried, the fallout should be of the trivial kind.
Also, mind basing it on the
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote:
>
> 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
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:
On Sat, 28 Jul 2007, Len Brown wrote:
>
> That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume.
Explain that to me.
There should *be* no resume.
ACPI doesn't suspend/resume on its own, I hope.
It is all done by the top-level suspend/resume code, not by ACPI. ACPI is
a pure
On Thursday 26 July 2007 16:55, Linus Torvalds wrote:
> Anyway, I think the ACPI problem really is as trivial as the following
> three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't
> force it on him.
...
> - # for sleep
> - select HOTPLUG_CPU if X86 && SMP
> -
On Thursday 26 July 2007 16:55, Linus Torvalds wrote:
Anyway, I think the ACPI problem really is as trivial as the following
three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't
force it on him.
...
- # for sleep
- select HOTPLUG_CPU if X86 SMP
- select
On Sat, 28 Jul 2007, Len Brown wrote:
That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume.
Explain that to me.
There should *be* no resume.
ACPI doesn't suspend/resume on its own, I hope.
It is all done by the top-level suspend/resume code, not by ACPI. ACPI is
a pure
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:
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote:
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
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote:
OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require
quite a bit of (compilation) testing on different architectures.
Sure. I'm not too worried, the fallout should be of the trivial kind.
Also, mind basing it on the
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
>
> My point is we have ACPI dependent on PM, so if you want ACPI, you end
> up with all of the STR stuff built in, which is what you don't like (if I
> understand that correctly). If we have CONFIG_SUSPEND, you'll be able to
> choose ACPI alone.
On Thursday, 26 July 2007 21:57, Linus Torvalds wrote:
>
> On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> >
> > Hmm, perhaps we should introduce a CONFIG_SUSPEND and change
> > CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on
> > CONFIG_PM?
> >
> > There's quite some code
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
>
> Hmm, perhaps we should introduce a CONFIG_SUSPEND and change
> CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on
> CONFIG_PM?
>
> There's quite some code needed only for suspend compiled in when CONFIG_PM is
> set ...
Sounds
On Thursday, 26 July 2007 19:45, Len Brown wrote:
> On Thursday 26 July 2007 02:55, Linus Torvalds wrote:
> >
> > On Thu, 26 Jul 2007, Len Brown wrote:
> > >
> > > Feel free to share what you know about the benefits vs. the costs
> > > of maintaining CONFIG_ACPI_SLEEP as a build option.
> >
> >
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
Hmm, perhaps we should introduce a CONFIG_SUSPEND and change
CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on
CONFIG_PM?
There's quite some code needed only for suspend compiled in when CONFIG_PM is
set ...
Sounds like a
On Thursday, 26 July 2007 21:57, Linus Torvalds wrote:
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
Hmm, perhaps we should introduce a CONFIG_SUSPEND and change
CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on
CONFIG_PM?
There's quite some code needed only for
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
My point is we have ACPI dependent on PM, so if you want ACPI, you end
up with all of the STR stuff built in, which is what you don't like (if I
understand that correctly). If we have CONFIG_SUSPEND, you'll be able to
choose ACPI alone. :-)
On Thursday, 26 July 2007 19:45, Len Brown wrote:
On Thursday 26 July 2007 02:55, Linus Torvalds wrote:
On Thu, 26 Jul 2007, Len Brown wrote:
Feel free to share what you know about the benefits vs. the costs
of maintaining CONFIG_ACPI_SLEEP as a build option.
Why don't you
24 matches
Mail list logo
