* Re: [PATCH] x86: revert "x86: Fix S4 regression"
[not found] ` <500D20A1.1030800@redhat.com>
@ 2012-07-23 11:22 ` Takao Indoh
2012-07-23 12:51 ` Dave Young
2012-07-24 15:55 ` Cong Wang
0 siblings, 2 replies; 11+ messages in thread
From: Takao Indoh @ 2012-07-23 11:22 UTC (permalink / raw)
To: dyoung
Cc: yinghai.lu, amwang, tiwai, kexec, linux-kernel, rjw, hpa,
xiyou.wangcong, akpm
(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 0x00000000-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:
>> [<ffffffff8158549b>] panic+0xb8/0x1c8
>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>> [<ffffffff8157304c>] init_memory_mapping+0x46c/0x530
>> [<ffffffff818a73c7>] setup_arch+0x669/0xb0e
>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>> [<ffffffff818a3a1f>] start_kernel+0x9b/0x34a
>> [<ffffffff818a332d>] x86_64_start_reservations+0x131/0x136
>> [<ffffffff818a341f>] 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 <xiyou.wangcong@gmail.com>
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 <xiyou.wangcong@gmail.com>
>>>
>>> This reverts the following commit:
>>>
>>> commit 8548c84da2f47e71bbbe300f55edb768492575f7
>>> Author: Takashi Iwai <tiwai@suse.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.
>>>
>>> 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 <caiqian@redhat.com>
>>> Cc: Dave Young <dyoung@redhat.com>
>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>> Cc: Rafael J. Wysocki <rjw@sisk.pl>
>>> Cc: Yinghai Lu <yinghai.lu@oracle.com>
>>> Cc: Takashi Iwai <tiwai@suse.de>
>>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>>>
>>> ---
>>> 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)
>>>
>
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-07-23 11:22 ` [PATCH] x86: revert "x86: Fix S4 regression" Takao Indoh
@ 2012-07-23 12:51 ` Dave Young
2012-07-24 15:55 ` Cong Wang
1 sibling, 0 replies; 11+ messages in thread
From: Dave Young @ 2012-07-23 12:51 UTC (permalink / raw)
To: Takao Indoh
Cc: yinghai.lu, amwang, tiwai, kexec, linux-kernel, rjw, hpa,
xiyou.wangcong, akpm
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 0x00000000-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:
>>> [<ffffffff8158549b>] panic+0xb8/0x1c8
>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>>> [<ffffffff8157304c>] init_memory_mapping+0x46c/0x530
>>> [<ffffffff818a73c7>] setup_arch+0x669/0xb0e
>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>>> [<ffffffff818a3a1f>] start_kernel+0x9b/0x34a
>>> [<ffffffff818a332d>] x86_64_start_reservations+0x131/0x136
>>> [<ffffffff818a341f>] 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 <xiyou.wangcong@gmail.com>
> 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 <xiyou.wangcong@gmail.com>
>>>>
>>>> This reverts the following commit:
>>>>
>>>> commit 8548c84da2f47e71bbbe300f55edb768492575f7
>>>> Author: Takashi Iwai <tiwai@suse.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.
>>>>
>>>> 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 <caiqian@redhat.com>
>>>> Cc: Dave Young <dyoung@redhat.com>
>>>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>>>> Cc: Rafael J. Wysocki <rjw@sisk.pl>
>>>> Cc: Yinghai Lu <yinghai.lu@oracle.com>
>>>> Cc: Takashi Iwai <tiwai@suse.de>
>>>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>>>>
>>>> ---
>>>> 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-07-23 11:22 ` [PATCH] x86: revert "x86: Fix S4 regression" Takao Indoh
2012-07-23 12:51 ` Dave Young
@ 2012-07-24 15:55 ` Cong Wang
2012-07-25 0:19 ` Takao Indoh
1 sibling, 1 reply; 11+ messages in thread
From: Cong Wang @ 2012-07-24 15:55 UTC (permalink / raw)
To: Takao Indoh
Cc: yinghai.lu, tiwai, kexec, linux-kernel, rjw, hpa, xiyou.wangcong,
akpm, dyoung
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 0x00000000-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:
> >> [<ffffffff8158549b>] panic+0xb8/0x1c8
> >> [<ffffffff8158565d>] ? printk+0x48/0x4a
> >> [<ffffffff8157304c>] init_memory_mapping+0x46c/0x530
> >> [<ffffffff818a73c7>] setup_arch+0x669/0xb0e
> >> [<ffffffff8158565d>] ? printk+0x48/0x4a
> >> [<ffffffff818a3a1f>] start_kernel+0x9b/0x34a
> >> [<ffffffff818a332d>] x86_64_start_reservations+0x131/0x136
> >> [<ffffffff818a341f>] 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 <xiyou.wangcong@gmail.com>
> 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!
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-07-24 15:55 ` Cong Wang
@ 2012-07-25 0:19 ` Takao Indoh
2012-08-06 20:42 ` Vivek Goyal
2012-08-11 17:57 ` Jerry Snitselaar
0 siblings, 2 replies; 11+ messages in thread
From: Takao Indoh @ 2012-07-25 0:19 UTC (permalink / raw)
To: amwang
Cc: yinghai.lu, tiwai, kexec, linux-kernel, rjw, hpa, xiyou.wangcong,
akpm, dyoung
(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 0x00000000-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:
>>>> [<ffffffff8158549b>] panic+0xb8/0x1c8
>>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>>>> [<ffffffff8157304c>] init_memory_mapping+0x46c/0x530
>>>> [<ffffffff818a73c7>] setup_arch+0x669/0xb0e
>>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
>>>> [<ffffffff818a3a1f>] start_kernel+0x9b/0x34a
>>>> [<ffffffff818a332d>] x86_64_start_reservations+0x131/0x136
>>>> [<ffffffff818a341f>] 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 <xiyou.wangcong@gmail.com>
>> 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-07-25 0:19 ` Takao Indoh
@ 2012-08-06 20:42 ` Vivek Goyal
2012-08-06 21:55 ` Yinghai Lu
2012-08-11 17:57 ` Jerry Snitselaar
1 sibling, 1 reply; 11+ messages in thread
From: Vivek Goyal @ 2012-08-06 20:42 UTC (permalink / raw)
To: Takao Indoh
Cc: rjw, amwang, tiwai, kexec, linux-kernel, yinghai.lu, hpa,
xiyou.wangcong, akpm, dyoung
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 0x00000000-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:
> >>>> [<ffffffff8158549b>] panic+0xb8/0x1c8
> >>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
> >>>> [<ffffffff8157304c>] init_memory_mapping+0x46c/0x530
> >>>> [<ffffffff818a73c7>] setup_arch+0x669/0xb0e
> >>>> [<ffffffff8158565d>] ? printk+0x48/0x4a
> >>>> [<ffffffff818a3a1f>] start_kernel+0x9b/0x34a
> >>>> [<ffffffff818a332d>] x86_64_start_reservations+0x131/0x136
> >>>> [<ffffffff818a341f>] 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 <xiyou.wangcong@gmail.com>
> >>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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-08-06 20:42 ` Vivek Goyal
@ 2012-08-06 21:55 ` Yinghai Lu
0 siblings, 0 replies; 11+ messages in thread
From: Yinghai Lu @ 2012-08-06 21:55 UTC (permalink / raw)
To: Vivek Goyal, Ingo Molnar, Linus Torvalds, H. Peter Anvin
Cc: Takao Indoh, amwang, tiwai, kexec, linux-kernel, rjw,
xiyou.wangcong, akpm, dyoung
On Mon, Aug 6, 2012 at 1:42 PM, Vivek Goyal <vgoyal@redhat.com> 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-07-25 0:19 ` Takao Indoh
2012-08-06 20:42 ` Vivek Goyal
@ 2012-08-11 17:57 ` Jerry Snitselaar
2012-08-11 18:26 ` Jerry Snitselaar
1 sibling, 1 reply; 11+ messages in thread
From: Jerry Snitselaar @ 2012-08-11 17:57 UTC (permalink / raw)
To: Takao Indoh
Cc: yinghai.lu, amwang, tiwai, kexec, linux-kernel, rjw, hpa,
xiyou.wangcong, akpm, dyoung
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-08-11 17:57 ` Jerry Snitselaar
@ 2012-08-11 18:26 ` Jerry Snitselaar
2012-08-11 18:34 ` H. Peter Anvin
0 siblings, 1 reply; 11+ messages in thread
From: Jerry Snitselaar @ 2012-08-11 18:26 UTC (permalink / raw)
To: Takao Indoh, amwang, dyoung, linux-kernel, akpm, xiyou.wangcong,
hpa, rjw, yinghai.lu, tiwai, kexec
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-08-11 18:26 ` Jerry Snitselaar
@ 2012-08-11 18:34 ` H. Peter Anvin
2012-08-11 18:39 ` H. Peter Anvin
2012-08-11 19:33 ` Tejun Heo
0 siblings, 2 replies; 11+ messages in thread
From: H. Peter Anvin @ 2012-08-11 18:34 UTC (permalink / raw)
To: Takao Indoh, amwang, dyoung, linux-kernel, akpm, xiyou.wangcong,
rjw, yinghai.lu, tiwai, kexec
Cc: Tejun Heo
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-08-11 18:34 ` H. Peter Anvin
@ 2012-08-11 18:39 ` H. Peter Anvin
2012-08-11 19:33 ` Tejun Heo
1 sibling, 0 replies; 11+ messages in thread
From: H. Peter Anvin @ 2012-08-11 18:39 UTC (permalink / raw)
To: Takao Indoh, amwang, dyoung, linux-kernel, akpm, xiyou.wangcong,
rjw, yinghai.lu, tiwai, kexec
Cc: Tejun Heo, Jacob Shin
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] x86: revert "x86: Fix S4 regression"
2012-08-11 18:34 ` H. Peter Anvin
2012-08-11 18:39 ` H. Peter Anvin
@ 2012-08-11 19:33 ` Tejun Heo
1 sibling, 0 replies; 11+ messages in thread
From: Tejun Heo @ 2012-08-11 19:33 UTC (permalink / raw)
To: H. Peter Anvin
Cc: yinghai.lu, Takao Indoh, amwang, tiwai, kexec, linux-kernel, rjw,
xiyou.wangcong, akpm, dyoung
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-08-11 19:33 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1339478463-31172-1-git-send-email-amwang@redhat.com>
[not found] ` <5004D8BF.6050205@jp.fujitsu.com>
[not found] ` <500D20A1.1030800@redhat.com>
2012-07-23 11:22 ` [PATCH] x86: revert "x86: Fix S4 regression" Takao Indoh
2012-07-23 12:51 ` Dave Young
2012-07-24 15:55 ` Cong Wang
2012-07-25 0:19 ` Takao Indoh
2012-08-06 20:42 ` Vivek Goyal
2012-08-06 21:55 ` Yinghai Lu
2012-08-11 17:57 ` Jerry Snitselaar
2012-08-11 18:26 ` Jerry Snitselaar
2012-08-11 18:34 ` H. Peter Anvin
2012-08-11 18:39 ` H. Peter Anvin
2012-08-11 19:33 ` Tejun Heo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).