[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABqxG0eF2=PJPMLGm3uzr-D-BSEneB0tnOAzg0zEmMBszs0i1A@mail.gmail.com>
Date: Wed, 21 Mar 2012 16:17:03 +0800
From: Dave Young <hidave.darkstar@...il.com>
To: Yinghai Lu <yinghai@...nel.org>
Cc: CAI Qian <caiqian@...hat.com>, Takashi Iwai <tiwai@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: crash dump memory reservation regression
On Tue, Mar 13, 2012 at 1:31 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Sun, Mar 11, 2012 at 8:00 PM, CAI Qian <caiqian@...hat.com> wrote:
>> commit 3661ca66a42e306aaf53246fb75aec1ea01be0f0
>> x86, memblock: Fix crashkernel allocation
>>
>> introduced a regression that crashkernel=512M
>> according to bisecting will fail like this,
>>
>> crashkernel reservation failed - No suitable area found.
>> The full dmesg can be found here.
>>
>> http://people.redhat.com/qcai/dmesg.bad
>
> The reason is: we put pagetable for [0,2g) just blow 512M.
>
> Later we have other patches that will put pagetable for [0,2g) just
> below 2g. even at that time we only can access 512M, because we use
> early_ioremap to access page table.
>
> But that good_end part get reverted in following because it cause s4
> resume fail.
>
> So there will be pagetable around just below 512M again. So you have
> no chance to get 512M below 768M.
>
> Solution will be:
> 1. remove the good_end setting for 64 bit again. and root cause S4 resume.
Takashi, could you check if latest kernel without the good_end patch
below works for you?
> 2. get page low?
> 3. fix kdump, and make kdump could take two ranges, one is small
> segment below 512M, other part could be more than 4G.
>
> Thanks
>
> Yinghai
>
>
> commit 8548c84da2f47e71bbbe300f55edb768492575f7
> Author: Takashi Iwai <tiwai@...e.de>
> Date: Sun Oct 23 23:19:12 2011 +0200
>
> x86: Fix S4 regression
>
> 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.
>
> Signed-off-by: Takashi Iwai <tiwai@...e.de>
> Cc: <stable@...nel.org>
> Cc: Rafael J. Wysocki <rjw@...k.pl>
> Cc: Yinghai Lu <yinghai.lu@...cle.com>
> [ We'll hopefully find the real fix, but that's too late for 3.1 now ]
> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>
> 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)
> --
> 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/
--
Regards
Dave
--
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/
Powered by blists - more mailing lists