makedumpfile: support for newer kernels [v4.9 onwards]

[Abhishek Shah]

Hi All,

I was finally able to root cause the issue that I was facing in the
kdump compressed output
generated by makedumpfile.

While debugging "write_kdump_pages_and_bitmap_cyclic"; I came to know that
somehow "info->max_mapnr" was modified/ reduced.

Seeing further, I could see that the "get_mem_map" function at the end
[if (!is_xen_memory())]
is attempting to change "info->max_mapnr" value based on "mem=" option.
-- in particular commit ebe2fa3a5c1e2bfac3778c0fbeca4287a934cc58.
And in my kernel command line, "mem=2G" was present, as I intended to
take dump of 2G RAM,
resulting into reduced "info->max_mapnr".

So, I commented out this portion and confirmed that "info->max_mapnr"
remains same
throughout. And I was able to get kdump compressed vmcore process-able
by crash utility.

Just to summarize:
Following was the problem statement: crash was giving "seek error"
while makedumpfile generated kdump-compressed vmcore was getting analyzed.
Details:
> The output generated by makedumpfile gets processed by crash utility
> if I use following command:
> makedumpfile -E /proc/vmcore vmcore
>
> But, the output generated by following command (which I used while
> reporting the issue) gives the "seek error" while being processed by
> crash.
> makedumpfile /proc/vmcore vmcore
>
> (As a result?), output from following command gives "seek error" as
> well while being processed by crash:
> makedumpfile -c /proc/vmcore vmcore

Following is my setup details:
>>> Kernel config:
>>> ARM64_VA_BITS_48 [=y]
>>> ARM64_PAGE_SHIFT [=12]
>>> RANDOMIZE_BASE [=n]
>>> ARM64_4K_PAGES [=y]

> kernel: 4.12- rc5
> yocto based rootfs: Pyro[2.3] which has kexec 2.0.14 and makedumpfile 1.6.1.
> crash: 7.1.9++ [Head: 4d517ad28acd845fe6e91360e645cf0446a4757b]


Thanks,
Abhishek