From: Liu hua <sdu.liu@huawei.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>
Cc: "will.deacon@arm.com" <will.deacon@arm.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"peifeiyue@huawei.com" <peifeiyue@huawei.com>,
"liusdu@126.com" <liusdu@126.com>
Subject: Re: [RFC PATCH 2/2] makedumpfile: get additional information from vmcore
Date: Tue, 13 May 2014 15:25:26 +0800 [thread overview]
Message-ID: <5371C8E6.6080700@huawei.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE97210369@BPXM01GP.gisp.nec.co.jp>
On 2014/5/13 14:21, Atsushi Kumagai wrote:
> Hello Liu,
>
>> Now we define MAX_PHYSMEM_BITS and SECTION_SIZE_BITS as
>> macros. So if we deal with vmcores with different values
>> of these two macros. We have to recompile makedumpfile.
>
> There are other macros which have architecture-specific values
> (e.g. __PAGE_OFFSET), and some functions are specific to each
> architecture (e.g. vaddr_to_paddr()), so we need recompilation
> eventually.
>
> OTOH, we already don't need recompilation for the same architecture
> since the values of such macros are defined for each kernel version
> like below:
>
> #ifdef __x86_64__
> ...
> #define _MAX_PHYSMEM_BITS_ORIG (40)
> #define _MAX_PHYSMEM_BITS_2_6_26 (44)
> #define _MAX_PHYSMEM_BITS_2_6_31 (46)
>
> So I don't think this patch is valuable.
Hi Atsushi,
For x86, it is not necessory. But for arm, different venders
may define different SECTION_SIZE_BITS. for example:
1 arch/arm/mach-clps711x/include/mach/memory.h
#define SECTION_SIZE_BITS 24
2 arch/arm/mach-exynos/include/mach/memory.h
#define SECTION_SIZE_BITS 28
4 arch/arm/mach-hisi/include/mach/memory.h
#define SECTION_SIZE_BITS 26
8 arch/arm/mach-sa1100/include/mach/memory.h
#define SECTION_SIZE_BITS 27
Perhaps we should find another way to let the userspace tools
to get the architecture-specific values.
Liu Hua
>
>
> Thanks
> Atsushi Kumagai
>
>> This patch makes makedumpfile get these two values from
>> vmcore info, if existing. It makes the makedumpfile more
>> compatible to vmcores with different section size.
>>
>> Signed-off-by: Liu Hua <sdu.liu@huawei.com>
>> ---
>> makedumpfile.c | 17 +++++++++++++++++
>> makedumpfile.h | 2 ++
>> 2 files changed, 19 insertions(+)
>>
>> diff --git a/makedumpfile.c b/makedumpfile.c
>> index 6cf6e24..3cdf323 100644
>> --- a/makedumpfile.c
>> +++ b/makedumpfile.c
>> @@ -2111,6 +2111,8 @@ read_vmcoreinfo(void)
>> READ_NUMBER("PG_slab", PG_slab);
>> READ_NUMBER("PG_buddy", PG_buddy);
>> READ_NUMBER("PG_hwpoison", PG_hwpoison);
>> + READ_NUMBER("SECTION_SIZE_BITS", SECTION_SIZE_BITS);
>> + READ_NUMBER("MAX_PHYSMEM_BITS", MAX_PHYSMEM_BITS);
>>
>> READ_SRCFILE("pud_t", pud_t);
>>
>> @@ -2998,6 +3000,18 @@ initialize_bitmap_memory(void)
>> }
>>
>> int
>> +calibrate_machdep_info(void)
>> +{
>> + if (NUMBER(MAX_PHYSMEM_BITS) > 0)
>> + info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
>> +
>> + if (NUMBER(SECTION_SIZE_BITS) > 0)
>> + info->section_size_bits = NUMBER(SECTION_SIZE_BITS);
>> +
>> + return TRUE;
>> +}
>> +
>> +int
>> initial(void)
>> {
>> off_t offset;
>> @@ -3214,6 +3228,9 @@ out:
>> if (debug_info && !get_machdep_info())
>> return FALSE;
>>
>> + if (debug_info && !calibrate_machdep_info())
>> + return FALSE;
>> +
>> if (is_xen_memory() && !get_dom0_mapnr())
>> return FALSE;
>>
>> diff --git a/makedumpfile.h b/makedumpfile.h
>> index eb03688..7acb23a 100644
>> --- a/makedumpfile.h
>> +++ b/makedumpfile.h
>> @@ -1434,6 +1434,8 @@ struct number_table {
>> long PG_hwpoison;
>>
>> long PAGE_BUDDY_MAPCOUNT_VALUE;
>> + long SECTION_SIZE_BITS;
>> + long MAX_PHYSMEM_BITS;
>> };
>>
>> struct srcfile_table {
>> --
>> 1.9.0
>
> .
>
next prev parent reply other threads:[~2014-05-13 7:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 13:27 [RFC PATCH 0/2] transfer sparse memory related values Liu Hua
2014-05-07 13:27 ` [RFC PATCH 1/2] kdump: add sparse memory related values to vmcore Liu Hua
2014-05-07 13:27 ` [RFC PATCH 2/2] makedumpfile: get additional information from vmcore Liu Hua
2014-05-13 6:21 ` Atsushi Kumagai
2014-05-13 7:25 ` Liu hua [this message]
2014-05-14 7:53 ` Atsushi Kumagai
2014-05-14 12:33 ` Liu hua
2014-05-15 2:12 ` Atsushi Kumagai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5371C8E6.6080700@huawei.com \
--to=sdu.liu@huawei.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=liusdu@126.com \
--cc=peifeiyue@huawei.com \
--cc=wangnan0@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox