Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 11:14:26 -0700	[thread overview]
Message-ID: <48B83C82.3060100@sgi.com> (raw)
In-Reply-To: <48B79B17.8050307@mxs.nes.nec.co.jp>

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

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:~ #

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);
> _
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec



[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2008-08-29 18:15 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 [this message]
2008-08-29 20:12                             ` Jay Lan
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=48B83C82.3060100@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