All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.