S4 sleep woes

S4 sleep woes

[Bernard Blackham]

The following bug was observed when using Software Suspend 2
(softwaresuspend.berlios.de), but the bug itself lies in the ACPI
code (neither in-kernel suspend-to-disk implementations work on my
laptop, so I can't test it).

Recent versions of Software Suspend 2 have an option to use ACPI S4
support to halt the machine, that (indirectly) calls
acpi_pm_prepare(4) and acpi_pm_enter(4).

The problem is that by default, this makes my machine hang with the
sleep light flashing instead of powering off.

In 2.6.7:

>From drivers/acpi/sleep/main.c (acpi_sleep_init):

        if (i == ACPI_STATE_S4) {
            if (acpi_gbl_FACS->S4bios_f) {
                sleep_states[i] = 1;
                printk(" S4bios");
                acpi_pm_ops.pm_disk_mode = PM_DISK_FIRMWARE; <---
            } else if (sleep_states[i])
                acpi_pm_ops.pm_disk_mode = PM_DISK_PLATFORM; <---
        }

With reference to the lines pointed out, if the machine claims that
its BIOS supports S4 itself, then pm_disk_mode is set to
PM_DISK_FIRMWARE.

Later on, in acpi_pm_enter:
    case PM_SUSPEND_DISK:
        if (acpi_pm_ops.pm_disk_mode == PM_DISK_PLATFORM)
            status = acpi_enter_sleep_state(acpi_state);
        else
            do_suspend_lowlevel_s4bios();
        break;

Hence, if pm_disk_mode is PM_DISK_FIRMWARE (because the BIOS claims
it can do S4), then do_suspend_lowlevel_s4bios() is called.

Now, according to the ACPI spec (2.0c, section 9.1.4.2 - The S4BIOS
transition), "the BIOS then saves the appropriate memory and chip
set context, and then places the platform into the S4 state (power
off to all devices)."

In the pmdisk/swsusp/software-suspend-2 case, this clearly isn't
desirable, as we've just saved memory ourselves.

If I force pm_disk_mode = PM_DISK_PLATFORM, then my machine uses
acpi_enter_sleep_state in order to sleep, and all works well. It
does shutdown as intended, and even better, shaves about 10 seconds
off the 30 second BIOS boot time when resuming.

>From what I gather, with pmdisk or swsusp, pm_disk_mode should never
be PM_DISK_FIRMWARE, as that essentially asks the BIOS to do S4 for
us.

Thoughts?

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: S4 sleep woes

[Karol Kozimor]

Thus wrote Bernard Blackham:
> From what I gather, with pmdisk or swsusp, pm_disk_mode should never
> be PM_DISK_FIRMWARE, as that essentially asks the BIOS to do S4 for
> us.

Didn't the /sys/power/* interface allow to choose between platform or
firmware at some point?
Best regards,

-- 
Karol 'sziwan' Kozimor
-@public.gmane.org


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: S4 sleep woes

[Bernard Blackham]

On Sat, Jul 31, 2004 at 05:01:12PM +0200, Karol Kozimor wrote:
> Thus wrote Bernard Blackham:
> > From what I gather, with pmdisk or swsusp, pm_disk_mode should never
> > be PM_DISK_FIRMWARE, as that essentially asks the BIOS to do S4 for
> > us.
> 
> Didn't the /sys/power/* interface allow to choose between platform or
> firmware at some point?

Ah, there appears to be one, yes (disk_show and disk_store in
kernel/power/disk.c). Looking again, pmdisk appears to handle it
correctly (just a little jump of logic). Guess that means it's a bug
in software suspend 2. :)

Ta,

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: S4 sleep woes

[Nigel Cunningham]

Howdy.

On Sun, 2004-08-01 at 04:46, Bernard Blackham wrote:
> Ah, there appears to be one, yes (disk_show and disk_store in
> kernel/power/disk.c). Looking again, pmdisk appears to handle it
> correctly (just a little jump of logic). Guess that means it's a bug
> in software suspend 2. :)

I wasn't setting pm_disk_mode from suspend 2, but leaving it at it's
default. It looks to me (without testing it yet) like the fix is to
explicitly set pm_disk_mode to PM_DISK_PLATFORM when suspending and
restore the original value afterwards. Sound right, Patrick?

Regards,

Nigel



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: S4 sleep woes

[Pavel Machek]

Hi!

> > From what I gather, with pmdisk or swsusp, pm_disk_mode should never
> > be PM_DISK_FIRMWARE, as that essentially asks the BIOS to do S4 for
> > us.
> 
> Didn't the /sys/power/* interface allow to choose between platform or
> firmware at some point?

>From what I've seen, it can only do one of firmware and platform,
becuse you only have one acpi_pm_ops.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285