From: Jay Lan <jlan@sgi.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: Bernhard Walle <bwalle@suse.de>, kexec@lists.infradead.org
Subject: Re: [PATCH][ia64] Fix the difference between node_mem_map and node_start_pfn. (Re: makedumpfile fails on SGI machine)
Date: Fri, 29 Aug 2008 13:12:03 -0700 [thread overview]
Message-ID: <48B85813.2030709@sgi.com> (raw)
In-Reply-To: <48B83C82.3060100@sgi.com>
[-- Attachment #1: Type: text/plain, Size: 4569 bytes --]
Jay Lan wrote:
> Ken'ichi Ohmichi wrote:
>> Hi Bernhard, Jay,
>>
>> Bernhard Walle wrote:
>>> Hi Ken'ichi Ohmichi,
>>>
>>> * Jay Lan [2008-08-27 18:43]:
>>>> Thanks for your patch!
>>>>
>>>> I am wondering if the discontigmem kernel has a legitimate bug,
>>>> we probably should report it?
>>>>
>>>> I tested your patch on a machine that used to fail in executing
>>>> 'makedumpfile'. It now generated a dump file fine.
>>> thanks for the patch, I can also report that with the patch and with
>>> vmlinux it works now.
>> Thank you for the report. It's a good news :-)
>>
>>
>>> However, shouldn't we add that vmem_map to VMCOREINFO of the kernel?
>
> Hmm, it failed on a shub2 machine. (The previous on that worked was a
> shub1 machine, an A3700. An A4700 is a shub2.) I assumed the warning
> about kernel version 2.6.27 not supported was harmless?
>
> a4700rac:~ # /bin/makedumpfile-1.2.7-0.2 -c -d31 -x
> /boot/vmlinux-2.6.27-rc4-vanilla /proc/vmcore /diskdump/dumpfile
> Can't distinguish the pgtable.
> The kernel version is not supported.
> The created dumpfile may be incomplete.
> Excluding unnecessary pages : [ 0 %] readmem: Can't convert a
> virtual address(a07ffff9df8f5800) to offset.
> create_2nd_bitmap: Can't exclude unnecessary pages.
>
> makedumpfile Failed.
> a4700rac:~ #
Sorry, it was from makedumpfile-1.2.7-0.2. I should have used 1.2.8.
Here is another test. I used 2.6.26 kernel with your kernel patch
and 1.2.8 makedumpfile.
a4700rac:~ # /bin/makedumpfile-1.2.8 -c -d31 -D /proc/vmcore
/diskdump/dumpfile
LOAD (0)
phys_start : 6044000000
phys_end : 60447bd920
virt_start : a000000100000000
virt_end : a0000001007bd920
[bunch of other LOAD messages]
Linux kdump
max_mapnr : 2069efeb
num of NODEs : 33
Memory type : DISCONTIGMEM
mem_map (0)
mem_map : 0
pfn_start : 0
pfn_end : 600300
[bunch of other mem_map messages]
Copying data : [ 0 %]
Oops, the kdump kernel MCA'ed at this point! The system was rebooted.
But at least makedumpfile understood the /proc/vmcore.
I think MCA on copying data is a different issue. It MCA'ed even on
'cp /proc/vmcore /diskdump/vmcore' :(
- jay
>
> I will try your kernel patch next.
>
> Regards,
> - jay
>
>> I think that we would rather fix the kernel bug than add vmem_map to
>> VMCOREINFO of the kernel. If fixing it, makedumpfile does not need
>> vmem_map.
>>
>> The attached patch fixes the kernel bug, and makedumpfile can work without
>> '-x' option. I tested it on my ia64 none-NUMA machine, and it works fine.
>> Could you test the attached patch on your machine again ?
>>
>>
>> Thanks
>> Ken'ichi Ohmichi
>>
>> ---
>> [PATCH][ia64] Fix the difference between node_mem_map and node_start_pfn.
>>
>> makedumpfile[1] cannot run on ia64 discontigmem kernel, because the member
>> node_mem_map of struct pgdat_list has invalid value. This patch fixes it.
>>
>> node_start_pfn shows the start pfn of each node, and node_mem_map should
>> point 'struct page' of each node's node_start_pfn.
>> On my machine, node0's node_start_pfn shows 0x400 and its node_mem_map points
>> 0xa0007fffbf000000. This address is the same as vmem_map, so the node_mem_map
>> points 'struct page' of pfn 0, even if its node_start_pfn shows 0x400.
>>
>> The cause is due to the round down of min_pfn in count_node_pages().
>> This patch fixes it.
>>
>>
>> makedumpfile[1]: dump filtering command
>> https://sourceforge.net/projects/makedumpfile/
>>
>> Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
>> ---
>> --- a/arch/ia64/mm/discontig.c 2008-08-29 23:05:52.000000000 +0900
>> +++ b/arch/ia64/mm/discontig.c 2008-08-29 23:06:59.000000000 +0900
>> @@ -631,7 +631,6 @@ static __init int count_node_pages(unsig
>> (min(end, __pa(MAX_DMA_ADDRESS)) - start) >>PAGE_SHIFT;
>> #endif
>> start = GRANULEROUNDDOWN(start);
>> - start = ORDERROUNDDOWN(start);
>> end = GRANULEROUNDUP(end);
>> mem_data[node].max_pfn = max(mem_data[node].max_pfn,
>> end >> PAGE_SHIFT);
>> --- a/include/asm-ia64/meminit.h 2008-08-29 23:06:36.000000000 +0900
>> +++ b/include/asm-ia64/meminit.h 2008-08-29 23:06:48.000000000 +0900
>> @@ -47,7 +47,6 @@ extern int reserve_elfcorehdr(unsigned l
>> */
>> #define GRANULEROUNDDOWN(n) ((n) & ~(IA64_GRANULE_SIZE-1))
>> #define GRANULEROUNDUP(n) (((n)+IA64_GRANULE_SIZE-1) & ~(IA64_GRANULE_SIZE-1))
>> -#define ORDERROUNDDOWN(n) ((n) & ~((PAGE_SIZE<<MAX_ORDER)-1))
>>
>> #ifdef CONFIG_NUMA
>> extern void call_pernode_memory (unsigned long start, unsigned long len, void *func);
>> _
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-08-29 20:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 14:14 makedumpfile fails on SGI machine Bernhard Walle
2008-07-31 1:46 ` Ken'ichi Ohmichi
2008-07-31 8:47 ` Bernhard Walle
2008-07-31 10:25 ` Ken'ichi Ohmichi
2008-07-31 11:18 ` Bernhard Walle
2008-07-31 11:36 ` Ken'ichi Ohmichi
2008-07-31 11:38 ` Bernhard Walle
2008-08-05 12:07 ` Ken'ichi Ohmichi
2008-08-05 15:11 ` Bernhard Walle
2008-08-18 7:19 ` Ken'ichi Ohmichi
2008-08-18 11:00 ` Bernhard Walle
2008-08-19 12:14 ` Ken'ichi Ohmichi
2008-08-27 9:00 ` Ken'ichi Ohmichi
2008-08-28 1:43 ` Jay Lan
2008-08-28 4:33 ` Ken'ichi Ohmichi
2008-08-28 7:25 ` Bernhard Walle
2008-08-29 6:45 ` [PATCH][ia64] Fix the difference between node_mem_map and node_start_pfn. (Re: makedumpfile fails on SGI machine) Ken'ichi Ohmichi
2008-08-29 16:54 ` Bernhard Walle
2008-09-01 2:13 ` Ken'ichi Ohmichi
2008-08-29 18:14 ` Jay Lan
2008-08-29 20:12 ` Jay Lan [this message]
2008-09-01 2:32 ` Ken'ichi Ohmichi
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=48B85813.2030709@sgi.com \
--to=jlan@sgi.com \
--cc=bwalle@suse.de \
--cc=kexec@lists.infradead.org \
--cc=oomichi@mxs.nes.nec.co.jp \
/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