run resume code only for S1-S4 states

Nate Lawson nate at root.org
Mon Apr 20 16:05:03 UTC 2009


Andriy Gapon wrote:
> on 18/04/2009 19:28 Nate Lawson said the following:
>> Fabian Keil wrote:
>>> Andriy Gapon <avg at freebsd.org> wrote:
>>>
>>>> An updated version of the patch, the only difference is: do-while(0) is gone,
>>>> breaks are replaces with gotos, indentation is reduced.
>>>>
>>>> Per Nate's request I am calling for people with SMP systems to test if powering
>>>> off via power button still works with this change. It's desirable to test power
>>>> off at least two times to increase a chance of non-BSP CPU being used.
>>> With an AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2542.15-MHz K8-class CPU)
>>> the first few shutdowns were successful, but on the fourth try pressing the
>>> power button only lead to:
>>>
>>> Apr 18 12:52:42 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:42 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> Apr 18 12:52:43 kendra kernel: acpi: suspend request ignored (not ready yet)
>>> Apr 18 12:52:43 kendra kernel: acpi: request to enter state S5 failed (err 6)
>>> [...]
>> Yes, I think the case for S5 should probably come before
>> acpi_sleep_disable().
> 
> Right now the patch tries to preserve the same behavior in this respect
> as the current code has. I don't have a good understanding of
> overlapping requests to enter different sleep states and potential bad
> effects (e.g. S1 request while soft power off is already in progress).
> 
> But in this case I actually wonder what left ACPI driver is "sleep
> disabled" state. Did the first soft poweroff attempt fail and caused
> subsequent attempts to be disabled? Hmm, if so, then I wonder why it
> could have failed.

It's a good question. Better to figure out why the first poweroff failed.

-- 
Nate


More information about the freebsd-acpi mailing list