From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754057Ab1JXJCR (ORCPT ); Mon, 24 Oct 2011 05:02:17 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60631 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753773Ab1JXJCQ (ORCPT ); Mon, 24 Oct 2011 05:02:16 -0400 Date: Mon, 24 Oct 2011 11:02:14 +0200 Message-ID: From: Takashi Iwai To: Yinghai Lu Cc: Takashi Iwai , Linus Torvalds , "Rafael J.Wysocki" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: Fix S4 regression In-Reply-To: <4EA4B164.4000009@oracle.com> References: <4EA4B164.4000009@oracle.com> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Sun, 23 Oct 2011 17:29:24 -0700, Yinghai Lu wrote: > > On 10/23/2011 02:19 PM, Takashi Iwai wrote: > > > The commit 4b239f458: [x86-64, mm: Put early page table high] causes > > a S4 regression since 2.6.39, namely the machine reboots occasionally > > at S4 resume. It doesn't happen always, overall rate is about 1/20. > > But, like other bugs, once when this happens, it continues to happen. > > > > This patch fixes the problem by essentially reverting the memory > > assignment in the older way. > > > > Cc: > > Signed-off-by: Takashi Iwai > > > > --- > > I resend this as a "fix" patch now before it's forgotten and rotten. > > It's just papering again over the mystery, but IMO better than the > > hard-reset behavior as of now. Unfortunately, bisection is pretty > > much difficult because the bug itself is fairly unstable... > > > > Did you try to check several commit that Rafael pointed out: > > > On Wed, Sep 28, 2011 at 12:30 PM, Rafael J. Wysocki wrote: > > On Wednesday, September 28, 2011, Takashi Iwai wrote: > >> > >> If my previous test -- 2.6.37+Yinghai's patches didn't show the > >> problem -- is correct, it means that some change in 2.6.38 reacted > >> badly with Yinghai's patches, not about 2.6.39. I'll check tomorrow > >> again whether this observation is really correct. > > > > Yes, that would be good to know, thanks for doing this! > > > > If that turns out to be the case, there are the following commits > > looking like worth checking: > > > > d344e38 x86, nx: Mark the ACPI resume trampoline code as +x > > 884b821 ACPI: Fix acpi_os_read_memory() and acpi_os_write_memory() (v2) > > d551d81 ACPI / PM: Call suspend_nvs_free() earlier during resume > > 2d6d9fd ACPI: Introduce acpi_os_ioremap() Yes, but these are harmless, as far as I've tested. Takashi