On 5/23/21 3:56 PM, Simon Horman wrote:
On Wed, May 19, 2021 at 11:16:21AM +0800, Pingfan Liu wrote:
Since kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the physical address of 'Kernel code' in
/proc/iomem is mapped from _text, instead, from
On 1/29/21 10:40 AM, kazuhito.ha...@gmail.com wrote:
From: Kazuhito Hagio
Linux 5.4 and later kernels for arm64 changed the kernel VA space
arrangement and introduced 52-bit kernel VAs by merging branch
commit b333b0ba2346. Support 5.9+ kernels with vmcoreinfo entries
and 5.4+ kernels with
On 1/15/21 8:40 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
Hi Pingfan, Bhupesh,
Thank you for your comments!
-Original Message-
Hi Kazu,
On Thu, Jan 14, 2021 at 3:33 PM piliu wrote:
On 1/14/21 4:25 PM, kazuhito.ha...@gmail.com wrote:
From: Kazuhito Hagio
Based on Bhupesh's patch
On 1/14/21 4:25 PM, kazuhito.ha...@gmail.com wrote:
From: Kazuhito Hagio
Based on Bhupesh's patch and contains Pingfan's idea.
Signed-off-by: Bhupesh Sharma
Signed-off-by: Kazuhito Hagio
---
arch/arm64.c | 95 --
makedumpfile.c
On 09/14/2020 05:15 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> -Original Message-
>> On 09/14/2020 04:15 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>> -Original Message-
On 09/11/2020 04:53 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
> -Original Message-
>>
On 09/14/2020 04:15 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> -Original Message-
>> On 09/11/2020 04:53 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>> Hi Pingfan,
>>>
>>> -Original Message-
Hello,
There is an appeal which only wants to save some user page including env
and
On 09/11/2020 04:53 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
> -Original Message-
>> Hello,
>>
>> There is an appeal which only wants to save some user page including env
>> and args pages, and discards the other user space pages.
>
> I understand that it's helpful to get them
Hello,
There is an appeal which only wants to save some user page including env
and args pages, and discards the other user space pages.
To achieve this feature, mm_struct's members "arg_start, arg_end,
env_start, env_end;" should be accessed. So we need to export mm_struct
and init_mm through
On 07/27/2020 03:36 AM, Hari Bathini wrote:
> Sorry! There was a gateway issue on my system while posting v5, due to
> which some patches did not make it through. Resending...
>
> This patch series enables kdump support for kexec_file_load system
> call (kexec -s -p) on PPC64. The changes are
On 07/03/2020 03:53 AM, Hari Bathini wrote:
> This patch series enables kdump support for kexec_file_load system
> call (kexec -s -p) on PPC64. The changes are inspired from kexec-tools
> code but heavily modified for kernel consumption. There is scope to
> expand purgatory to verify sha256
On 07/01/2020 03:40 PM, Dave Young wrote:
> Hi Hari,
> On 06/27/20 at 12:35am, Hari Bathini wrote:
>> crashkernel region could have an overlap with special memory regions
>> like opal, rtas, tce-table & such. These regions are referred to as
>> exclude memory ranges. Setup this ranges during
On 06/30/2020 02:10 PM, Hari Bathini wrote:
>
>
> On 30/06/20 9:00 am, piliu wrote:
>>
>>
>> On 06/29/2020 01:55 PM, Hari Bathini wrote:
>>>
>>>
>>> On 28/06/20 7:44 am, piliu wrote:
>>>> Hi Hari,
>>>
>>> Hi
On 06/29/2020 01:55 PM, Hari Bathini wrote:
>
>
> On 28/06/20 7:44 am, piliu wrote:
>> Hi Hari,
>
> Hi Pingfan,
>
>>
>> After a quick through for this series, I have a few question/comment on
>> this patch for the time being. Pls see comment
Hi Hari,
If in [4/11], get_exclude_memory_ranges() turns out to be unnecessary
,then this patch is abundant either. As my understanding, memblock has
already helped to achieved the purpose that get_exclude_memory_ranges()
wants.
Thanks,
Pingfan
On 06/27/2020 03:04 AM, Hari Bathini wrote:
>
Hi Hari,
After a quick through for this series, I have a few question/comment on
this patch for the time being. Pls see comment inline.
On 06/27/2020 03:05 AM, Hari Bathini wrote:
> crashkernel region could have an overlap with special memory regions
> like opal, rtas, tce-table & such. These
On 04/29/2020 10:27 PM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
>> -Original Message-
>> Hi Kazu and Cascardo,
>>
>> I encounter a weird problem when running makedumpfile on a s390 machine.
>>
>> Our production kernel uses extreme sparse memory model, and has the
>> following:
>>
Hi Kazu and Cascardo,
I encounter a weird problem when running makedumpfile on a s390 machine.
Our production kernel uses extreme sparse memory model, and has the
following:
in mm/sparse.c
#ifdef CONFIG_SPARSEMEM_EXTREME
struct mem_section **mem_section;
#else
struct mem_section
On 04/14/2020 03:09 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Pingfan,
>
>> -Original Message-
>> The crashed kernel passes usable RAM info through pt_loads[], but the
>> current code ignore this, and parse all sections below info->max_mapnr.
>> Refer to code in get_mm_sparsemem()
>>
On 04/02/2020 01:49 PM, Dave Young wrote:
> On 03/26/20 at 06:07pm, James Morse wrote:
>> Memory added to the system by hotplug has a 'System RAM' resource created
>> for it. This is exposed to user-space via /proc/iomem.
>>
>> This poses problems for kexec on arm64. If kexec decides to place
ld not validate mem_section.
get_mm_sparsemem: Can't get the address of mem_section.
makedumpfile Failed.
Thanks,
Pingfan
>
> Thanks,
> Kazu
>
> -Original Message-
>> On 02/12/2020 12:11 PM, piliu wrote:
>>>
>>>
>>> On 02/06/2020 11:46 AM
On 02/12/2020 12:11 PM, piliu wrote:
>
>
> On 02/06/2020 11:46 AM, piliu wrote:
>>
>>
>> On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>>> -Original Message-
>>>> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
>
On 02/06/2020 11:46 AM, piliu wrote:
>
>
> On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>>> -Original Message-
>>> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
>>>> Hi,
>>>>
>>>> Sorry to reply late due
On 02/05/2020 05:18 AM, HAGIO KAZUHITO(萩尾 一仁) wrote:
>> -Original Message-
>> On Tue, Feb 04, 2020 at 02:24:17PM +0800, piliu wrote:
>>> Hi,
>>>
>>> Sorry to reply late due to a long festival.
>>>
>>> I have tested this patch ag
Hi,
Sorry to reply late due to a long festival.
I have tested this patch against v4.15 and latest kernel with small
modification to meet the situation we discussed here. Both work fine.
The below is the modification of two kernel
test1. latest kernel with two extra modification to expose the
On 01/20/2020 04:59 PM, Baoquan He wrote:
> On 01/20/20 at 09:33am, David Hildenbrand wrote:
>>
>>
>>> Am 20.01.2020 um 03:25 schrieb Pingfan Liu :
>>>
>>> After kernel commit ba72b4c8cf60 ("mm/sparsemem: support sub-section
>>> hotplug"), when hot-removed, section_mem_map is still encoded with
On 12/12/2019 01:44 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
>> -Original Message-
>>> Reading the code, I think
>>> - the issue might occur not only in refiltering, but also the first
>>> filtering
>>> with --split and --work-dir option (forced non-cyclic mode).
>>> - pefer to
On 12/10/2019 04:10 AM, Kazuhito Hagio wrote:
>
>> -Original Message-
>> From: piliu
>> Sent: Monday, December 9, 2019 1:06 AM
>> To: Hagio Kazuhito(萩尾 一仁) ; kexec@lists.infradead.org
>> Subject: Re: [PATCH] makedumpfile: assign bitmap2 fd for s
On 12/07/2019 06:11 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
>> -Original Message-
>> In refiltering mode, each sub process inherits bitmap2->fd from parent.
>> Then they lseek()/read() on the same fd, which means that they interference
>> with each other.
>>
>> This breaks the
On 12/07/2019 12:28 AM, Kazuhito Hagio wrote:
>> -Original Message-
>>
>> On 12/05/2019 06:36 AM, Kazuhito Hagio wrote:
>>> Hi Pingfan,
>>>
>>> Thank you for the patch.
>>>
-Original Message-
since the following commit, -lebl has been removed from elfutils.
commit
On 12/05/2019 06:36 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
> Thank you for the patch.
>
>> -Original Message-
>> since the following commit, -lebl has been removed from elfutils.
>> commit b833c731359af12af9f16bcb621b3cdc170eafbc
>> Author: Mark Wielaard
>> Date: Thu Aug 29
NACKed by myself due to a misunderstand of the code.
On 11/19/2019 11:11 AM, Pingfan Liu wrote:
> is_dumpable_file() is inconsistent with write_kdump_bitmap_file().
> In the former one, bitmap->offset takes account for the header. But the
> later one does not.
>
> It makes things more mussy
On 08/07/2018 03:56 AM, Kazuhito Hagio wrote:
> Hello Pingfan,
>
> Thank you for the v2 update.
>
> On 8/2/2018 11:16 PM, Pingfan Liu wrote:
>> When refiltering on kdump format file, there is no info about pt_load[] for
>> exclude_nodata_pages(), and also we can not expect more data than the
On 08/03/2018 03:22 AM, Kazuhito Hagio wrote:
> On 8/2/2018 3:36 AM, piliu wrote:
>>
>>
>> On 08/02/2018 04:45 AM, Kazuhito Hagio wrote:
>>> Hi Pingfan,
>>>
>>> Thank you for the patch.
>>>
>>> On 7/31/2018 4:44 AM, Pingfan Liu w
On 08/02/2018 04:45 AM, Kazuhito Hagio wrote:
> Hi Pingfan,
>
> Thank you for the patch.
>
> On 7/31/2018 4:44 AM, Pingfan Liu wrote:
>> When refiltering on kdump format file, there is no info about pt_load[] for
>> exclude_nodata_pages(), and also we can not expect more data than the kdump
34 matches
Mail list logo
