Re: makedumpfile: get_max_mapnr() from ELF header problem

[Michael Holzheu <holzheu@linux.vnet.ibm.com>]

On Wed, 12 Mar 2014 06:01:47 +0000
Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> wrote:

> >(2014/02/28 21:41), Michael Holzheu wrote:
> >> Hello Atsushi,

[snip]

> >Looking into source code a little, max_mapnr is used only for calculating a size of two bitmaps. I guess there's any
> >s390-specific issue.
> 
> On second thought, Michael's log looks strange.
> 
> >> Excluding unnecessary pages        : [ 21 %] vtop_s390x: Address too big for the number of page table levels.
> >> readmem: Can't convert a virtual address(8000180104670) to physical address.
> >> readmem: type_addr: 0, addr:8000180104670, size:32768
> >> __exclude_unnecessary_pages: Can't read the buffer of struct page.
> 
> This message was shown during translating the virtual address of mem_map
> to the physical address:
> 
> __exclude_unnecessary_pages():
> 
>         if (!readmem(VADDR, mem_map,
>             page_cache + (index_pg * SIZE(page)),
>             SIZE(page) * pfn_mm)) {
>                 ERRMSG("Can't read the buffer of struct page.\n");
>                 return FALSE;
>         }
> 
> However, this should succeed even if mem= was specified because the
> corresponding page table must exist in the memory image since it was
> used by kernel actually. The address translation logic may have an issue.

To be honest I don't really understand what happens when the error occurs.

My test is a 1 TiB dump of a Linux system that has set mem=1G.

With makedumpfile 1.5.3 I see the following stack backtrace:

(gdb) bt
#0  vtop_s390x (vaddr=2251803034918936) at ./arch/s390x.c:236
#1  0x000000008001de44 in vaddr_to_paddr_s390x (vaddr=2251803034918936)
    at ./arch/s390x.c:300
#2  0x000000008001fb50 in readmem (type_addr=0, addr=2251803034918936, 
    bufptr=0x3ffffff6cf0, size=32768) at makedumpfile.c:349
#3  0x0000000080034cf2 in __exclude_unnecessary_pages (
    mem_map=2251803034918936, pfn_start=16777216, pfn_end=16842752)
    at makedumpfile.c:4189
#4  0x0000000080035716 in exclude_unnecessary_pages_cyclic ()
    at makedumpfile.c:4349
#5  0x00000000800358e4 in update_cyclic_region (pfn=0) at makedumpfile.c:4380
#6  0x00000000800384e0 in get_num_dumpable_cyclic () at makedumpfile.c:5060
#7  0x0000000080036850 in create_dump_bitmap () at makedumpfile.c:4585
#8  0x00000000800429c8 in create_dumpfile () at makedumpfile.c:7533
#9  0x00000000800490fc in main (argc=5, argv=0x3fffffff3d8)
    at makedumpfile.c:8651

Looks like makdumpfile wants to read a virtual address 2251803034918936
(hex 0x80000C0002018) which can't be resolved by the three level kernel
page table (max is 4 TiB here).

In the __exclude_unnecessary_pages() function the variables have the
following values:

(gdb) print pfn_end
$1 = 16842752
(gdb) print pfn
$2 = 16777216
(gdb) print pfn_start
$3 = 16777216
(gdb) print mem_map
$4 = 2251803034918936

I would appreciate any hints!

Michael


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