[2.6.25-rc1 regression] Suspend to RAM (bisected)

[Carlos R. Mafra]

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...@intel.com <venkatesh...@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...@intel.com>
Signed-off-by: Len Brown <len....@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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Arjan van de Ven]

On Mon, 11 Feb 2008 03:25:33 -0200
"Carlos R. Mafra" <crm...@gmail.com> wrote:

> 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.

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 ar...@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org

[Calvin Walton]

On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote:
> 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...@intel.com <venkatesh...@intel.com>
> Date: Thu Jan 31 17:35:04 2008 -0800
>
> ACPI: enable MWAIT for C1 idle

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.

You beat me emailing the issue to the list by a few minutes :)

> 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.

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
dmesg; this apparently happens before the "return to C".

> 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).

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

> 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])

Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo,
and a GM965 chip (using uvesafb)

>
> If there is anything else I can do to help please let me know.
>
> Carlos R. Mafra

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

[Carlos R. Mafra]

Arjan van de Ven wrote:
> On Mon, 11 Feb 2008 03:25:33 -0200
> "Carlos R. Mafra" <crm...@gmail.com> wrote:
>
>> 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.
>
>
> 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 ;(

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

Thanks for the prompt answer!

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Calvin Walton [mailto:calvin...@gmail.com]
>Sent: Sunday, February 10, 2008 9:48 PM
>To: Carlos R. Mafra
>Cc: linux-...@vger.kernel.org; Pallipadi, Venkatesh
>Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
>
>On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote:
>> 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...@intel.com <venkatesh...@intel.com>
>> Date: Thu Jan 31 17:35:04 2008 -0800
>>
>> ACPI: enable MWAIT for C1 idle
>
>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.
>

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

[Carlos R. Mafra]

Pallipadi, Venkatesh wrote:
>> -----Original Message-----
>> From: Calvin Walton [mailto:calvin...@gmail.com]
>> Sent: Sunday, February 10, 2008 9:48 PM
>> To: Carlos R. Mafra
>> Cc: linux-...@vger.kernel.org; Pallipadi, Venkatesh
>> Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
>>
>> On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote:
>>> 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...@intel.com <venkatesh...@intel.com>
>>> Date: Thu Jan 31 17:35:04 2008 -0800
>>>
>>> ACPI: enable MWAIT for C1 idle
>> 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.
>>
>
> 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.

Full dmesg and acpidump outputs are attached.

> Thanks,
> Venki

Thank you for looking at it,
Carlos

[Venki Pallipadi]

On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
> Pallipadi, Venkatesh wrote:
> >
> > 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.
>
> Full dmesg and acpidump outputs are attached.

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

[Venki Pallipadi]

On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
> > Pallipadi, Venkatesh wrote:
> > >
> > > 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.
> >
> > Full dmesg and acpidump outputs are attached.
>
> 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 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...@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);

[Carlos R. Mafra]

Venki Pallipadi wrote:
> On Mon, Feb 11, 2008 at 12:06:50PM -0800, Venki Pallipadi wrote:
>> On Mon, Feb 11, 2008 at 05:37:04PM -0200, Carlos R. Mafra wrote:
>>> Pallipadi, Venkatesh wrote:
>>>> 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.
>>> Full dmesg and acpidump outputs are attached.
>> 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 for sending the dumps Carlos.
>
> The patch below (on top of rc1) should fix the problem. Can you please
> check it.

I tested your patch and it fixes the problem here!

Thank you very much for your good work,
Carlos

[Len Brown]

Applied.

thanks,
-Len