Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Sat, Aug 11, 2012 at 11:34:22AM -0700, H. Peter Anvin wrote: > On 08/11/2012 11:26 AM, Jerry Snitselaar wrote: > >> > >>This patch from Jacob Shin solves the problem, and seems like it might > >>be a better solution. > >> > >>[PATCH 2/5] x86: find_early_table_space based on memory ranges that > >>are being mapped > >> > >>https://lkml.org/lkml/2012/8/9/540 > >> > >Actually, apply that series of 5 patches. > > > > I was hoping Tejun would comment on it, but I think I'll pull it into -tip. Wasn't cc'd. Will take a look. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On 08/11/2012 11:34 AM, H. Peter Anvin wrote: On 08/11/2012 11:26 AM, Jerry Snitselaar wrote: This patch from Jacob Shin solves the problem, and seems like it might be a better solution. [PATCH 2/5] x86: find_early_table_space based on memory ranges that are being mapped https://lkml.org/lkml/2012/8/9/540 Actually, apply that series of 5 patches. I was hoping Tejun would comment on it, but I think I'll pull it into -tip. However, the real question is what we should do for -stable; applying the full patch series seems a big aggressive for that. On the other hand, if it really is The Right Thing then perhaps we should do so anyway. Ah, right... still waiting for a rev of the patch to address Yinghai's legitimate request for minor code restructuring. Other than that, the patchset is really The Right Thing. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On 08/11/2012 11:26 AM, Jerry Snitselaar wrote: This patch from Jacob Shin solves the problem, and seems like it might be a better solution. [PATCH 2/5] x86: find_early_table_space based on memory ranges that are being mapped https://lkml.org/lkml/2012/8/9/540 Actually, apply that series of 5 patches. I was hoping Tejun would comment on it, but I think I'll pull it into -tip. However, the real question is what we should do for -stable; applying the full patch series seems a big aggressive for that. On the other hand, if it really is The Right Thing then perhaps we should do so anyway. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Sat Aug 11 12, Jerry Snitselaar wrote: > On Wed Jul 25 12, Takao Indoh wrote: > > >Thanks for tracking this, Takao! > > > > > >I bet you are using x86_64 not x86 PAE? If so, could you try this patch > > >https://patchwork.kernel.org/patch/1195751/ > > >? I already reviewed it. > > > > Great, I applied it and now kdump works. Thanks! > > > > Thanks, > > Takao Indoh > > > > This patch from Jacob Shin solves the problem, and seems like it might > be a better solution. > > [PATCH 2/5] x86: find_early_table_space based on memory ranges that > are being mapped > > https://lkml.org/lkml/2012/8/9/540 > Actually, apply that series of 5 patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Wed Jul 25 12, Takao Indoh wrote: > >Thanks for tracking this, Takao! > > > >I bet you are using x86_64 not x86 PAE? If so, could you try this patch > >https://patchwork.kernel.org/patch/1195751/ > >? I already reviewed it. > > Great, I applied it and now kdump works. Thanks! > > Thanks, > Takao Indoh > This patch from Jacob Shin solves the problem, and seems like it might be a better solution. [PATCH 2/5] x86: find_early_table_space based on memory ranges that are being mapped https://lkml.org/lkml/2012/8/9/540 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Mon, Aug 6, 2012 at 1:42 PM, Vivek Goyal wrote: > > Did something happen on this patch. We definitely want to gain back the > capability to be able to reserve 512MB of kdump memory. Maybe Ingo and peter could push that to Linus. Assume we have Acked-by from you, me and others. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Wed, Jul 25, 2012 at 09:19:08AM +0900, Takao Indoh wrote: > (2012/07/25 0:55), Cong Wang wrote: > >On Mon, 2012-07-23 at 20:22 +0900, Takao Indoh wrote: > >>(2012/07/23 19:00), Dave Young wrote: > >>>On 07/17/2012 11:15 AM, Takao Indoh wrote: > >>> > Hi Cong, > > When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump > kernel's panic in find_early_table_space(). > > init_memory_mapping: [mem 0x-0x36ffafff] > Kernel panic - not syncing: Cannot find space for the kernel page tables > Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17 > Call Trace: > [] panic+0xb8/0x1c8 > [] ? printk+0x48/0x4a > [] init_memory_mapping+0x46c/0x530 > [] setup_arch+0x669/0xb0e > [] ? printk+0x48/0x4a > [] start_kernel+0x9b/0x34a > [] x86_64_start_reservations+0x131/0x136 > [] x86_64_start_kernel+0xed/0xf4 > > In find_early_table_space(), a kernel tries to find free area below 512M > for pgtable using memblock_find_in_range, but it fails because kdump > kernel does not have enough free space below 512M due to the memmap > restriction. This is the memmap option specified against kdump kernel > when crashkernel=128M. > > memmap=560K@64K memmap=130492K@770608K > > Only 560KB area is available and it is not sufficient for pgtable (it > seems that about 1.8MB area is needed for pgtable). This problem is > fixed by your revert patch. I hope this patch gets merged. > >>> > >>> > >>>I can reproduce this issue as well, probably related to some x86 mm init > >>>commits, this alloc failure does not happen with reverting below commits: > >>> > >>>bd2753b2dda7bb43c7468826de75f49c6a7e8965 > >>>722bc6b16771ed80871e1fd81c86d3627dda2ac8 > >>Yeah, my result of bisect is as follows and at first I thought the > >>commit 722bc6 caused this regression. > >> > >>722bc6b16771ed80871e1fd81c86d3627dda2ac8 is the first bad commit > >>commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 > >>Author: WANG Cong > >>Date: Mon Mar 5 15:05:13 2012 -0800 > >> > >>IIUC, this commit just fixes a bug of counting pgtable entries. As the > >>result, another problem came up to the surface. In the case of my > >>machine(16GB memory), before applying 722bc6, find_early_table_space() > >>requests about 12KB free area and it can be got from 560K@64K area > >>luckily. I think the size find_early_table_space() requests was a bug. > >>After the bug is fixed by the commit 722bc6, find_early_table_space() > >>requires 1.8MB area and it fails as I wrote. > > > >Thanks for tracking this, Takao! > > > >I bet you are using x86_64 not x86 PAE? If so, could you try this patch > >https://patchwork.kernel.org/patch/1195751/ > >? I already reviewed it. > > Great, I applied it and now kdump works. Thanks! Did something happen on this patch. We definitely want to gain back the capability to be able to reserve 512MB of kdump memory. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
(2012/07/25 0:55), Cong Wang wrote: On Mon, 2012-07-23 at 20:22 +0900, Takao Indoh wrote: (2012/07/23 19:00), Dave Young wrote: On 07/17/2012 11:15 AM, Takao Indoh wrote: Hi Cong, When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump kernel's panic in find_early_table_space(). init_memory_mapping: [mem 0x-0x36ffafff] Kernel panic - not syncing: Cannot find space for the kernel page tables Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17 Call Trace: [] panic+0xb8/0x1c8 [] ? printk+0x48/0x4a [] init_memory_mapping+0x46c/0x530 [] setup_arch+0x669/0xb0e [] ? printk+0x48/0x4a [] start_kernel+0x9b/0x34a [] x86_64_start_reservations+0x131/0x136 [] x86_64_start_kernel+0xed/0xf4 In find_early_table_space(), a kernel tries to find free area below 512M for pgtable using memblock_find_in_range, but it fails because kdump kernel does not have enough free space below 512M due to the memmap restriction. This is the memmap option specified against kdump kernel when crashkernel=128M. memmap=560K@64K memmap=130492K@770608K Only 560KB area is available and it is not sufficient for pgtable (it seems that about 1.8MB area is needed for pgtable). This problem is fixed by your revert patch. I hope this patch gets merged. I can reproduce this issue as well, probably related to some x86 mm init commits, this alloc failure does not happen with reverting below commits: bd2753b2dda7bb43c7468826de75f49c6a7e8965 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Yeah, my result of bisect is as follows and at first I thought the commit 722bc6 caused this regression. 722bc6b16771ed80871e1fd81c86d3627dda2ac8 is the first bad commit commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Author: WANG Cong Date: Mon Mar 5 15:05:13 2012 -0800 IIUC, this commit just fixes a bug of counting pgtable entries. As the result, another problem came up to the surface. In the case of my machine(16GB memory), before applying 722bc6, find_early_table_space() requests about 12KB free area and it can be got from 560K@64K area luckily. I think the size find_early_table_space() requests was a bug. After the bug is fixed by the commit 722bc6, find_early_table_space() requires 1.8MB area and it fails as I wrote. Thanks for tracking this, Takao! I bet you are using x86_64 not x86 PAE? If so, could you try this patch https://patchwork.kernel.org/patch/1195751/ ? I already reviewed it. Great, I applied it and now kdump works. Thanks! Thanks, Takao Indoh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On Mon, 2012-07-23 at 20:22 +0900, Takao Indoh wrote: > (2012/07/23 19:00), Dave Young wrote: > > On 07/17/2012 11:15 AM, Takao Indoh wrote: > > > >> Hi Cong, > >> > >> When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump > >> kernel's panic in find_early_table_space(). > >> > >> init_memory_mapping: [mem 0x-0x36ffafff] > >> Kernel panic - not syncing: Cannot find space for the kernel page tables > >> Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17 > >> Call Trace: > >> [] panic+0xb8/0x1c8 > >> [] ? printk+0x48/0x4a > >> [] init_memory_mapping+0x46c/0x530 > >> [] setup_arch+0x669/0xb0e > >> [] ? printk+0x48/0x4a > >> [] start_kernel+0x9b/0x34a > >> [] x86_64_start_reservations+0x131/0x136 > >> [] x86_64_start_kernel+0xed/0xf4 > >> > >> In find_early_table_space(), a kernel tries to find free area below 512M > >> for pgtable using memblock_find_in_range, but it fails because kdump > >> kernel does not have enough free space below 512M due to the memmap > >> restriction. This is the memmap option specified against kdump kernel > >> when crashkernel=128M. > >> > >> memmap=560K@64K memmap=130492K@770608K > >> > >> Only 560KB area is available and it is not sufficient for pgtable (it > >> seems that about 1.8MB area is needed for pgtable). This problem is > >> fixed by your revert patch. I hope this patch gets merged. > > > > > > I can reproduce this issue as well, probably related to some x86 mm init > > commits, this alloc failure does not happen with reverting below commits: > > > > bd2753b2dda7bb43c7468826de75f49c6a7e8965 > > 722bc6b16771ed80871e1fd81c86d3627dda2ac8 > Yeah, my result of bisect is as follows and at first I thought the > commit 722bc6 caused this regression. > > 722bc6b16771ed80871e1fd81c86d3627dda2ac8 is the first bad commit > commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 > Author: WANG Cong > Date: Mon Mar 5 15:05:13 2012 -0800 > > IIUC, this commit just fixes a bug of counting pgtable entries. As the > result, another problem came up to the surface. In the case of my > machine(16GB memory), before applying 722bc6, find_early_table_space() > requests about 12KB free area and it can be got from 560K@64K area > luckily. I think the size find_early_table_space() requests was a bug. > After the bug is fixed by the commit 722bc6, find_early_table_space() > requires 1.8MB area and it fails as I wrote. Thanks for tracking this, Takao! I bet you are using x86_64 not x86 PAE? If so, could you try this patch https://patchwork.kernel.org/patch/1195751/ ? I already reviewed it. Sorry for the trouble! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On 07/23/2012 07:22 PM, Takao Indoh wrote:
> (2012/07/23 19:00), Dave Young wrote:
>> On 07/17/2012 11:15 AM, Takao Indoh wrote:
>>
>>> Hi Cong,
>>>
>>> When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
>>> kernel's panic in find_early_table_space().
>>>
>>> init_memory_mapping: [mem 0x-0x36ffafff]
>>> Kernel panic - not syncing: Cannot find space for the kernel page tables
>>> Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
>>> Call Trace:
>>> [] panic+0xb8/0x1c8
>>> [] ? printk+0x48/0x4a
>>> [] init_memory_mapping+0x46c/0x530
>>> [] setup_arch+0x669/0xb0e
>>> [] ? printk+0x48/0x4a
>>> [] start_kernel+0x9b/0x34a
>>> [] x86_64_start_reservations+0x131/0x136
>>> [] x86_64_start_kernel+0xed/0xf4
>>>
>>> In find_early_table_space(), a kernel tries to find free area below 512M
>>> for pgtable using memblock_find_in_range, but it fails because kdump
>>> kernel does not have enough free space below 512M due to the memmap
>>> restriction. This is the memmap option specified against kdump kernel
>>> when crashkernel=128M.
>>>
>>> memmap=560K@64K memmap=130492K@770608K
>>>
>>> Only 560KB area is available and it is not sufficient for pgtable (it
>>> seems that about 1.8MB area is needed for pgtable). This problem is
>>> fixed by your revert patch. I hope this patch gets merged.
>>
>>
>> I can reproduce this issue as well, probably related to some x86 mm init
>> commits, this alloc failure does not happen with reverting below commits:
>>
>> bd2753b2dda7bb43c7468826de75f49c6a7e8965
>> 722bc6b16771ed80871e1fd81c86d3627dda2ac8
> Yeah, my result of bisect is as follows and at first I thought the
> commit 722bc6 caused this regression.
>
> 722bc6b16771ed80871e1fd81c86d3627dda2ac8 is the first bad commit
> commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
> Author: WANG Cong
> Date: Mon Mar 5 15:05:13 2012 -0800
>
> IIUC, this commit just fixes a bug of counting pgtable entries. As the
> result, another problem came up to the surface. In the case of my
> machine(16GB memory), before applying 722bc6, find_early_table_space()
> requests about 12KB free area and it can be got from 560K@64K area
> luckily. I think the size find_early_table_space() requests was a bug.
> After the bug is fixed by the commit 722bc6, find_early_table_space()
> requires 1.8MB area and it fails as I wrote.
Sounds reasonable, if find_early_table_space is ok then I also vote to
revert the s4 regression fix.
>
> Thanks,
> Takao Indoh
>
>>
>>>
>>> Thanks,
>>> Takao Indoh
>>>
>>> (2012/06/12 14:21), Cong Wang wrote:
From: Cong Wang
This reverts the following commit:
commit 8548c84da2f47e71bbbe300f55edb768492575f7
Author: Takashi Iwai
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.
According to the previous discussion:
http://marc.info/?l=linux-kernel&m=133161674120253&w=2
it seems that so far the best solution is just reverting it.
Takashi, could you help to test if the S4 regression is still
there after this patch?
Reported-by: CAI Qian
Cc: Dave Young
Cc: "H. Peter Anvin"
Cc: Rafael J. Wysocki
Cc: Yinghai Lu
Cc: Takashi Iwai
Signed-off-by: Cong Wang
---
arch/x86/mm/init.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index bc4e9d8..7ab7975 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -74,8 +74,9 @@ static void __init find_early_table_space(struct
map_range *mr, unsigned long en
#ifdef CONFIG_X86_32
/* for fixmap */
tables += roundup(__end_of_fixed_addresses * sizeof(pte_t),
PAGE_SIZE);
-#endif
+
good_end = max_pfn_mapped << PAGE_SHIFT;
+#endif
base = memblock_find_in_range(start, good_end, tables,
PAGE_SIZE);
if (!base)
>>
>>
>>
>
--
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
(2012/07/23 19:00), Dave Young wrote:
> On 07/17/2012 11:15 AM, Takao Indoh wrote:
>
>> Hi Cong,
>>
>> When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
>> kernel's panic in find_early_table_space().
>>
>> init_memory_mapping: [mem 0x-0x36ffafff]
>> Kernel panic - not syncing: Cannot find space for the kernel page tables
>> Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
>> Call Trace:
>> [] panic+0xb8/0x1c8
>> [] ? printk+0x48/0x4a
>> [] init_memory_mapping+0x46c/0x530
>> [] setup_arch+0x669/0xb0e
>> [] ? printk+0x48/0x4a
>> [] start_kernel+0x9b/0x34a
>> [] x86_64_start_reservations+0x131/0x136
>> [] x86_64_start_kernel+0xed/0xf4
>>
>> In find_early_table_space(), a kernel tries to find free area below 512M
>> for pgtable using memblock_find_in_range, but it fails because kdump
>> kernel does not have enough free space below 512M due to the memmap
>> restriction. This is the memmap option specified against kdump kernel
>> when crashkernel=128M.
>>
>> memmap=560K@64K memmap=130492K@770608K
>>
>> Only 560KB area is available and it is not sufficient for pgtable (it
>> seems that about 1.8MB area is needed for pgtable). This problem is
>> fixed by your revert patch. I hope this patch gets merged.
>
>
> I can reproduce this issue as well, probably related to some x86 mm init
> commits, this alloc failure does not happen with reverting below commits:
>
> bd2753b2dda7bb43c7468826de75f49c6a7e8965
> 722bc6b16771ed80871e1fd81c86d3627dda2ac8
Yeah, my result of bisect is as follows and at first I thought the
commit 722bc6 caused this regression.
722bc6b16771ed80871e1fd81c86d3627dda2ac8 is the first bad commit
commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
Author: WANG Cong
Date: Mon Mar 5 15:05:13 2012 -0800
IIUC, this commit just fixes a bug of counting pgtable entries. As the
result, another problem came up to the surface. In the case of my
machine(16GB memory), before applying 722bc6, find_early_table_space()
requests about 12KB free area and it can be got from 560K@64K area
luckily. I think the size find_early_table_space() requests was a bug.
After the bug is fixed by the commit 722bc6, find_early_table_space()
requires 1.8MB area and it fails as I wrote.
Thanks,
Takao Indoh
>
>>
>> Thanks,
>> Takao Indoh
>>
>> (2012/06/12 14:21), Cong Wang wrote:
>>> From: Cong Wang
>>>
>>> This reverts the following commit:
>>>
>>> commit 8548c84da2f47e71bbbe300f55edb768492575f7
>>> Author: Takashi Iwai
>>> 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.
>>>
>>> According to the previous discussion:
>>> http://marc.info/?l=linux-kernel&m=133161674120253&w=2
>>> it seems that so far the best solution is just reverting it.
>>>
>>> Takashi, could you help to test if the S4 regression is still
>>> there after this patch?
>>>
>>> Reported-by: CAI Qian
>>> Cc: Dave Young
>>> Cc: "H. Peter Anvin"
>>> Cc: Rafael J. Wysocki
>>> Cc: Yinghai Lu
>>> Cc: Takashi Iwai
>>> Signed-off-by: Cong Wang
>>>
>>> ---
>>>arch/x86/mm/init.c |3 ++-
>>>1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>>> index bc4e9d8..7ab7975 100644
>>> --- a/arch/x86/mm/init.c
>>> +++ b/arch/x86/mm/init.c
>>> @@ -74,8 +74,9 @@ static void __init find_early_table_space(struct
>>> map_range *mr, unsigned long en
>>>#ifdef CONFIG_X86_32
>>> /* for fixmap */
>>> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
>>> -#endif
>>> +
>>> good_end = max_pfn_mapped << PAGE_SHIFT;
>>> +#endif
>>>
>>> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
>>> if (!base)
>>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
On 07/17/2012 11:15 AM, Takao Indoh wrote:
> Hi Cong,
>
> When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
> kernel's panic in find_early_table_space().
>
> init_memory_mapping: [mem 0x-0x36ffafff]
> Kernel panic - not syncing: Cannot find space for the kernel page tables
> Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
> Call Trace:
> [] panic+0xb8/0x1c8
> [] ? printk+0x48/0x4a
> [] init_memory_mapping+0x46c/0x530
> [] setup_arch+0x669/0xb0e
> [] ? printk+0x48/0x4a
> [] start_kernel+0x9b/0x34a
> [] x86_64_start_reservations+0x131/0x136
> [] x86_64_start_kernel+0xed/0xf4
>
> In find_early_table_space(), a kernel tries to find free area below 512M
> for pgtable using memblock_find_in_range, but it fails because kdump
> kernel does not have enough free space below 512M due to the memmap
> restriction. This is the memmap option specified against kdump kernel
> when crashkernel=128M.
>
> memmap=560K@64K memmap=130492K@770608K
>
> Only 560KB area is available and it is not sufficient for pgtable (it
> seems that about 1.8MB area is needed for pgtable). This problem is
> fixed by your revert patch. I hope this patch gets merged.
I can reproduce this issue as well, probably related to some x86 mm init
commits, this alloc failure does not happen with reverting below commits:
bd2753b2dda7bb43c7468826de75f49c6a7e8965
722bc6b16771ed80871e1fd81c86d3627dda2ac8
>
> Thanks,
> Takao Indoh
>
> (2012/06/12 14:21), Cong Wang wrote:
>> From: Cong Wang
>>
>> This reverts the following commit:
>>
>> commit 8548c84da2f47e71bbbe300f55edb768492575f7
>> Author: Takashi Iwai
>> 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.
>>
>> According to the previous discussion:
>> http://marc.info/?l=linux-kernel&m=133161674120253&w=2
>> it seems that so far the best solution is just reverting it.
>>
>> Takashi, could you help to test if the S4 regression is still
>> there after this patch?
>>
>> Reported-by: CAI Qian
>> Cc: Dave Young
>> Cc: "H. Peter Anvin"
>> Cc: Rafael J. Wysocki
>> Cc: Yinghai Lu
>> Cc: Takashi Iwai
>> Signed-off-by: Cong Wang
>>
>> ---
>> arch/x86/mm/init.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index bc4e9d8..7ab7975 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -74,8 +74,9 @@ static void __init find_early_table_space(struct map_range
>> *mr, unsigned long en
>> #ifdef CONFIG_X86_32
>> /* for fixmap */
>> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
>> -#endif
>> +
>> good_end = max_pfn_mapped << PAGE_SHIFT;
>> +#endif
>>
>> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
>> if (!base)
>>
--
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: revert "x86: Fix S4 regression"
Hi Cong,
When I tested kdump with 3.5.0-rc6 kernel, I found a problem of kdump
kernel's panic in find_early_table_space().
init_memory_mapping: [mem 0x-0x36ffafff]
Kernel panic - not syncing: Cannot find space for the kernel page tables
Pid: 0, comm: swapper Not tainted 3.5.0-rc6 #17
Call Trace:
[] panic+0xb8/0x1c8
[] ? printk+0x48/0x4a
[] init_memory_mapping+0x46c/0x530
[] setup_arch+0x669/0xb0e
[] ? printk+0x48/0x4a
[] start_kernel+0x9b/0x34a
[] x86_64_start_reservations+0x131/0x136
[] x86_64_start_kernel+0xed/0xf4
In find_early_table_space(), a kernel tries to find free area below 512M
for pgtable using memblock_find_in_range, but it fails because kdump
kernel does not have enough free space below 512M due to the memmap
restriction. This is the memmap option specified against kdump kernel
when crashkernel=128M.
memmap=560K@64K memmap=130492K@770608K
Only 560KB area is available and it is not sufficient for pgtable (it
seems that about 1.8MB area is needed for pgtable). This problem is
fixed by your revert patch. I hope this patch gets merged.
Thanks,
Takao Indoh
(2012/06/12 14:21), Cong Wang wrote:
> From: Cong Wang
>
> This reverts the following commit:
>
> commit 8548c84da2f47e71bbbe300f55edb768492575f7
> Author: Takashi Iwai
> 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.
>
> According to the previous discussion:
> http://marc.info/?l=linux-kernel&m=133161674120253&w=2
> it seems that so far the best solution is just reverting it.
>
> Takashi, could you help to test if the S4 regression is still
> there after this patch?
>
> Reported-by: CAI Qian
> Cc: Dave Young
> Cc: "H. Peter Anvin"
> Cc: Rafael J. Wysocki
> Cc: Yinghai Lu
> Cc: Takashi Iwai
> Signed-off-by: Cong Wang
>
> ---
> arch/x86/mm/init.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index bc4e9d8..7ab7975 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -74,8 +74,9 @@ static void __init find_early_table_space(struct map_range
> *mr, unsigned long en
> #ifdef CONFIG_X86_32
> /* for fixmap */
> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
> -#endif
> +
> good_end = max_pfn_mapped << PAGE_SHIFT;
> +#endif
>
> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
> if (!base)
>
[0.00] Linux version 3.5.0-rc6 (root@localhost) (gcc version 4.4.6
20120305 (Red Hat 4.4.6-4) (GCC) ) #17 SMP Thu Jul 12 13:49:46 JST 2012
[0.00] Command line: ro root=UUID=1893a13e-19af-439b-9d39-0a42260f3eaa
rd_NO_LUKS rd_NO_MD KEYBOARDTYPE=pc KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_NO_LVM
rd_NO_DM loglevel=7 earlyprintk=serial,ttyS0,19200n8 irqpoll nr_cpus=1
reset_devices cgroup_disable=memory mce=off memmap=exactmap memmap=560K@64K
memmap=130492K@770608K elfcorehdr=901100K memmap=64K$0K memmap=16K$624K
memmap=112K$912K memmap=32832K$3103360K memmap=40K#3136192K memmap=4K#3136232K
memmap=9492K$3136236K memmap=262144K$3670016K memmap=1024K$4173824K
memmap=4K$4175872K memmap=17408K$4176896K
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x0100-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbd69] usable
[0.00] BIOS-e820: [mem 0xbd6a-0xbf6a] reserved
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6b9fff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6ba000-0xbf6bafff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf6bb000-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] bootconsole [earlyser0] enabled
[0.00] e820: last_pfn = 0x44 max_arch_pfn = 0x4
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0x] reserved
