From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545Ab1ITQMF (ORCPT ); Tue, 20 Sep 2011 12:12:05 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36889 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790Ab1ITQMD (ORCPT ); Tue, 20 Sep 2011 12:12:03 -0400 Date: Tue, 20 Sep 2011 18:12:02 +0200 Message-ID: From: Takashi Iwai To: linux-kernel@vger.kernel.org Cc: Yinghai Lu , "H. Peter Anvin" , oneukum@suse.de, rjw@sisk.pl, x86@kernel.org Subject: S4 resume broken since 2.6.39 (3.1, too) 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 Hi, during testing 3.0.4 kernels, I found that the S4 is broken in recent kernels since 2.6.39. The symptom is that the machine suddenly reboots after the S4 resume image is read. This happens only occasionally, usually within 10 or 20 S4 cycles. The problem is still found in 3.1-rc6. After a bisection, the likely culprit is: commit 4b239f458c229de044d6905c2b0f9fe16ed9e01e Author: Yinghai Lu Date: Fri Dec 17 16:58:28 2010 -0800 x86-64, mm: Put early page table high And the essential revert to fix the problem is like below. It reverts the memory assignment in the old way, and the diff of dmesg is something like: @@ -49,10 +49,10 @@ Base memory trampoline at [ffff880000098000] 98000 size 20480 init_memory_mapping: 0000000000000000-000000007a000000 0000000000 - 007a000000 page 2M -kernel direct mapping tables up to 7a000000 @ 7913f000-79142000 +kernel direct mapping tables up to 7a000000 @ 1fffd000-20000000 init_memory_mapping: 0000000100000000-0000000100600000 0100000000 - 0100600000 page 2M -kernel direct mapping tables up to 100600000 @ 1005fa000-100600000 +kernel direct mapping tables up to 100600000 @ 7913c000-79142000 RAMDISK: 36d36000 - 37ff0000 ACPI: RSDP 00000000000f2f10 00024 (v02 HPQOEM) ACPI: XSDT 0000000079ffe120 00094 (v01 HPQOEM SLIC-MPC 00000004 01000013) @@ -76,7 +76,7 @@ No NUMA configuration found Faking a node at 0000000000000000-0000000100600000 Initmem setup node 0 0000000000000000-0000000100600000 - NODE_DATA [00000001005d3000 - 00000001005f9fff] + NODE_DATA [00000001005d9000 - 00000001005fffff] [ffffea0000000000-ffffea00039fffff] PMD -> [ffff880076a00000-ffff8800787fffff] on node 0 Zone PFN ranges: DMA 0x00000010 -> 0x00001000 And S4 seems working more stably now. I still have no idea why the commit above introduced the buggy behavior. Through a quick look at the output above, the assigned areas look OK... Can anyone give a deeper insight? thanks, Takashi --- diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 3032644..87488b9 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -63,9 +63,8 @@ static void __init find_early_table_space(unsigned long end, int use_pse, #ifdef CONFIG_X86_32 /* for fixmap */ tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE); - - good_end = max_pfn_mapped << PAGE_SHIFT; #endif + good_end = max_pfn_mapped << PAGE_SHIFT; base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE); if (base == MEMBLOCK_ERROR)