Hi,

I want to report that suspend to RAM stopped working on my Sony Vaio 
VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down
to:

commit bc71bec91f9875ef825d12104acf3bf4ca215fa4
Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com>
Date:   Thu Jan 31 17:35:04 2008 -0800

    ACPI: enable MWAIT for C1 idle

    Add MWAIT idle for C1 state instead of halt, on platforms that support
    C1 state with MWAIT.

    Renames cx->space_id to something more appropriate.

    Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

The problem with suspend to RAM is that right after typing (from inside X)
'echo mem > /sys/power/state' the screen becomes black and the laptop 
freezes. I have to use SysRq+b to reboot.

I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but
the compilation fails. It turns out that I have to revert also 9a0b8415 and
9b12e18c to be able to compile without errors. 

After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel
can suspend to RAM again (and I must say that it is better that 2.6.24, because
now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to
go back to X as I used to do before).

The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the
following graphics card:
VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA])

If there is anything else I can do to help please let me know.

Carlos R. Mafra


--

[ message continues ]

On Mon, 11 Feb 2008 03:25:33 -0200


this may be a BIOS bug; I'll let Venki dig into this ... but can you send the output of
the dmidecode program to the list? If we need to start blacklisting bioses that information
is going to be needed ;(


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--

[ message continues ]

I am sending the dmidecode output attached (I erased the UUID).

Thanks for the prompt answer!





[ message continues ]

I normally hate to throw in a 'me-too', but I'm also seeing a
suspend-to-ram regression on my Thinkpad R61i that I've managed to
bisect down to the same patch series.


My symptoms in this case are slightly different - the suspend appears to
work correctly, and is fast. However, when I resume, the screen lights
up quickly, but the system hangs for nearly a minute with the suspend
light still on solid before it actually resumes. No delay is visible in

I just tried reverting the above-mentioned 3 commits, doing so fixes the

Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo,

-- 
Calvin Walton <calvin.walton@gmail.com>


--

[ message continues ]

Carlos, Calvin,

Can you send me the output of acpidump and full dmesg to me. Looks like
it is a platform issue due to which we cannot use C1 mwait idle during
suspend resume, something similar to issue we had with using C2/C3 state
during idle.

Thanks,
Venki 
--

[ message continues ]

Thank you for looking at it,
Carlos
 

[ message continues ]

Above acpidump doesnt have all info, as it is loading some SSDT at run time.
Can you get the output of

# acpidump --addr 0x7F6D8709 --length 0x000004B7
# acpidump --addr 0x7F6D8BC0 --length 0x00000092

Thanks,
Venki

--

[ message continues ]

Thanks for sending the dumps Carlos.

The patch below (on top of rc1) should fix the problem. Can you please
check it.

Thanks,
Venki


Earlier patch (bc71bec91f9875ef825d12104acf3bf4ca215fa4) broke
suspend resume on many laptops. The problem was reported by
Carlos R. Mafra and Calvin Walton, who bisected the issue to above patch.

The problem was because, C2 and C3 code were calling acpi_idle_enter_c1
directly, with C2 or C3 as state parameter, while suspend/resume was in
progress. The patch bc71bec started making use of that state information,
assuming that it would always be referring to C1 state. This caused the
problem with suspend-resume as we ended up using C2/C3 state indirectly.

Fix this by adding acpi_idle_suspend check in enter_c1.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

Index: linux-2.6.25-rc1/drivers/acpi/processor_idle.c
===================================================================
--- linux-2.6.25-rc1.orig/drivers/acpi/processor_idle.c
+++ linux-2.6.25-rc1/drivers/acpi/processor_idle.c
@@ -1420,6 +1420,14 @@ static int acpi_idle_enter_c1(struct cpu
 		return 0;
 
 	local_irq_disable();
+
+	/* Do not access any ACPI IO ports in suspend path */
+	if (acpi_idle_suspend) {
+		acpi_safe_halt();
+		local_irq_enable();
+		return 0;
+	}
+
 	if (pr->flags.bm_check)
 		acpi_idle_update_bm_rld(pr, cx);
 
--

[ message continues ]

I tested your patch and it fixes the problem here!

Thank you very much for your good work,

--

[ message continues ]

Applied.

thanks,
-Len

--

[ message continues ]