linux-kernel - Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080211232027.GA8206@linux-os.sc.intel.com>
Date:	Mon, 11 Feb 2008 15:20:27 -0800
From:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
To:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
Cc:	"Carlos R. Mafra" <crmafra@...il.com>,
	Calvin Walton <calvin.walton@...il.com>,
	linux-kernel@...r.kernel.org, Len Brown <lenb@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>, rjw@...k.pl
Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)

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.pallipadi@...el.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);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/