Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758277AbYBLAFe (ORCPT ); Mon, 11 Feb 2008 19:05:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753203AbYBLAF0 (ORCPT ); Mon, 11 Feb 2008 19:05:26 -0500 Received: from py-out-1112.google.com ([64.233.166.177]:27042 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751561AbYBLAFZ (ORCPT ); Mon, 11 Feb 2008 19:05:25 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lenzqCJWMkm4y4Xk3ABVYJrRu2rV1t57QmhxAEh/RDiqvElsJ+xe5AlHRvD0g1M2G0mbZwabRK1a9B3QPQa0jLYMuYCNJjZt6DPy0DavHVSyiZnYzP9LAYw0bhWYMisgysDSJ+cliycSVWH7t8y2/SsE9oKF7IAziBYIYx8t3LI= Message-ID: <47B0E395.7030800@gmail.com> Date: Mon, 11 Feb 2008 22:08:53 -0200 From: "Carlos R. Mafra" User-Agent: Thunderbird 2.0.0.6 (X11/20070914) MIME-Version: 1.0 To: Venki Pallipadi CC: Calvin Walton , linux-kernel@vger.kernel.org, Len Brown , Thomas Gleixner , rjw@sisk.pl Subject: Re: [2.6.25-rc1 regression] Suspend to RAM (bisected) References: <47AFDC4D.4070400@gmail.com> <1202708864.5206.0.camel@zem> <924EFEDD5F540B4284297C4DC59F3DEE8608D3@orsmsx423.amr.corp.intel.com> <47B0A3E0.4050908@gmail.com> <20080211200650.GA8287@linux-os.sc.intel.com> <20080211232027.GA8206@linux-os.sc.intel.com> In-Reply-To: <20080211232027.GA8206@linux-os.sc.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2510 Lines: 72 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 > 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 > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/