Re: makedumpfile fails on SGI machine

[Jay Lan <jlan@sgi.com>]

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

Ken'ichi Ohmichi wrote:
> Hi Bernhard,
> 
> Bernhard Walle wrote:
>>>> * Ken'ichi Ohmichi [2008-08-05 21:07]:
>>>>> BTW, I'd like to know some conditions of this problem.
>>>>> So please let me know the makedumpfile commandline which you run.
>>>>>  Ex. # makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile
>>>>   # makedumpfile -d 3 -D vmcore.sles11 vmcore.sles11.filtered
>>>>
>>>>> I doubt that makedumpfile cannot distinguish the pgtable correctly.
>>>>> I created the debugging patch. Please run makedumpfile-1.2.7 applied
>>>>> with it by '-D' option, and report the output.
>>>>> According to your kernel .config file, the output should contain
>>>>> "PAGETABLE_4L : ON".
>>>> See the attachment.
>>> Thanks for the log.
>>> makedumpfile can distinguish the pgtable correctly.
>>>
>>> Can the crash utility translate the virtual address 0xa0007fff8f900000
>>> to physical address ? Please run the following subcommand on the crash
>>> utility.
>>>
>>> crash> vtop 0xa0007fff8f900000
>> crash> vtop 0xa0007fff8f900000  
>> VIRTUAL           PHYSICAL        
>> a0007fff8f900000  (not mapped)
>>
>> PAGE DIRECTORY: a000000100914000
>>    PGD: a000000100914000 => 30030bc000
>>    PUD: e0000030030bfff8 => 30030c0000
>>    PMD: e0000030030c3e38 => 30030c4000
>>    PTE: e0000030030c7200 => 0
>>
>>
>> But I guess that's normal with virtual memory maps:
>>
>> $ zgrep VIRTUAL_M /proc/config.gz 
>> CONFIG_VIRTUAL_MEM_MAP=y
> 
> Thank you for your help.
> 
> I found an ia64 discontigmem kernel problem that the 'pgdat_list.node_mem_map'
> has an unexpected value, and I created the attached patch for avoiding the
> problem. If applying this patch, makedumpfile takes mem_map's information
> from a symbol 'vmem_map' instead of 'pgdat_list.node_mem_map'.
> It is for makedumpfile-1.2.8.  Could you please test it ?
> 
> Note:
>  This solution needs a symbol 'vmem_map', but vmcoreinfo data in /proc/vmcore
>  does not contain it. So "-x" option is necessary for running makedumpfile
>  like the following.
> 
>  # makedumpfile -c -d31 -x vmlinux /proc/vmcore dumpfile

Hi Ken'ichi,

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.

Running 4.0.7.1 crash against the dump file looked good!
I will test on other types machines later.

Thanks for your help (and Bernhard's) while i was chasing down
a nasty bug that panicked kdump kernel at boot with 2.6.27
kernel on an IA64 machine.

Regards,
 - jay

> 
> 
> Thanks
> Ken'ichi Ohmichi
> 
> diff -puN backup/v1.2.8/makedumpfile.c makedumpfile/makedumpfile.c
> --- backup/v1.2.8/makedumpfile.c	2008-08-12 12:17:24.000000000 +0900
> +++ makedumpfile/makedumpfile.c	2008-08-28 02:07:47.000000000 +0900
> @@ -1819,6 +1819,7 @@ get_symbol_info()
>  	 * Get symbol info.
>  	 */
>  	SYMBOL_INIT(mem_map, "mem_map");
> +	SYMBOL_INIT(vmem_map, "vmem_map");
>  	SYMBOL_INIT(mem_section, "mem_section");
>  	SYMBOL_INIT(pkmap_count, "pkmap_count");
>  	SYMBOL_INIT_NEXT(pkmap_count_next, "pkmap_count");
> @@ -2110,6 +2111,7 @@ generate_vmcoreinfo()
>  	 * write the symbol of 1st kernel
>  	 */
>  	WRITE_SYMBOL("mem_map", mem_map);
> +	WRITE_SYMBOL("vmem_map", vmem_map);
>  	WRITE_SYMBOL("mem_section", mem_section);
>  	WRITE_SYMBOL("pkmap_count", pkmap_count);
>  	WRITE_SYMBOL("pkmap_count_next", pkmap_count_next);
> @@ -2350,6 +2352,7 @@ read_vmcoreinfo()
>  		return FALSE;
>  
>  	READ_SYMBOL("mem_map", mem_map);
> +	READ_SYMBOL("vmem_map", vmem_map);
>  	READ_SYMBOL("mem_section", mem_section);
>  	READ_SYMBOL("pkmap_count", pkmap_count);
>  	READ_SYMBOL("pkmap_count_next", pkmap_count_next);
> @@ -2912,6 +2915,7 @@ get_mm_discontigmem()
>  {
>  	int i, j, id_mm, node, num_mem_map, separate_mm = FALSE;
>  	unsigned long pgdat, mem_map, pfn_start, pfn_end, node_spanned_pages;
> +	unsigned long vmem_map;
>  	struct mem_map_data temp_mmd;
>  
>  	num_mem_map = get_num_mm_discontigmem();
> @@ -2924,6 +2928,13 @@ get_mm_discontigmem()
>  		separate_mm = TRUE;
>  	}
>  
> +	if (SYMBOL(vmem_map) != NOT_FOUND_SYMBOL) {
> +		if (!readmem(VADDR, SYMBOL(vmem_map), &vmem_map, sizeof vmem_map)) {
> +			ERRMSG("Can't get vmem_map.\n");
> +			return FALSE;
> +		}
> +	}
> +
>  	/*
>  	 * Get the first node_id.
>  	 */
> @@ -2937,11 +2948,6 @@ get_mm_discontigmem()
>  	}
>  	id_mm = 0;
>  	for (i = 0; i < vt.numnodes; i++) {
> -		if (!readmem(VADDR, pgdat + OFFSET(pglist_data.node_mem_map),
> -		    &mem_map, sizeof mem_map)) {
> -			ERRMSG("Can't get mem_map.\n");
> -			return FALSE;
> -		}
>  		if (!readmem(VADDR, pgdat + OFFSET(pglist_data.node_start_pfn),
>  		    &pfn_start, sizeof pfn_start)) {
>  			ERRMSG("Can't get node_start_pfn.\n");
> @@ -2954,6 +2960,15 @@ get_mm_discontigmem()
>  		}
>  		pfn_end = pfn_start + node_spanned_pages;
>  
> +		if (SYMBOL(vmem_map) == NOT_FOUND_SYMBOL) {
> +			if (!readmem(VADDR, pgdat + OFFSET(pglist_data.node_mem_map),
> +			    &mem_map, sizeof mem_map)) {
> +				ERRMSG("Can't get mem_map.\n");
> +				return FALSE;
> +			}
> +		} else
> +			mem_map = vmem_map + SIZE(page) * pfn_start;
> +
>  		if (separate_mm) {
>  			/*
>  			 * For some ia64 NUMA systems.
> diff -puN backup/v1.2.8/makedumpfile.h makedumpfile/makedumpfile.h
> --- backup/v1.2.8/makedumpfile.h	2008-08-12 12:17:24.000000000 +0900
> +++ makedumpfile/makedumpfile.h	2008-08-28 02:06:40.000000000 +0900
> @@ -814,6 +814,7 @@ extern struct vm_table		vt;
>  
>  struct symbol_table {
>  	unsigned long long	mem_map;
> +	unsigned long long	vmem_map;
>  	unsigned long long	mem_section;
>  	unsigned long long	pkmap_count;
>  	unsigned long long	pkmap_count_next;
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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