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

On s390 we have the following little problem:

We use hypervisor or stand-alone dump tools to create Linux system
dumps. These tools do not know the kernel parameter line and dump the
full physical memory.

We use makedumpfile to filter those dumps.

If a Linux system has specified the "mem=" parameter, the dump tools
still dump the whole phypsical memory.

Unfortunately in "get_max_mapnr()" makedumpfile uses the ELF header to
get the maxmimum page frame number. Since this is not the correct value
in our case makedumpfile fails to filter the dump.

We get the following error on s390 with makedumpfile version 1.5.3:

makedumpfile -c -d 31 vmcore dump.kdump
cyclic buffer size has been changed: 22156083 => 22156032
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.
Excluding unnecessary pages        : [ 23 %] 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:327681.5.5 __exclude_unnecessary_pages:
Can't read the buffer of struct page.

Since version 1.5.4 makedumpfile seems to loop in __exclude_unnecessary_pages().

We thought about several ways to fix this problem but have not found a
good solution up to now.

Do you have an idea how we could fix that?

Best Regards,
Michael


At least on x86, makedumpfile appears to work well for dumps generated by 
sadump and virsh dump. In particular, virsh dump --memory-only generates dump 
in ELF, whose PT_LOAD entries are generated from RAM list managed by qemu, not 
managed by kernel.

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.

--
Thanks.
HATAYAMA, Daisuke


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to