Problems writing ELF dumps with makedumpfile 1.2.9

[Ken'ichi Ohmichi]

Hi Kevin,

Worth, Kevin wrote:
>> Could the fact that my kernel's page offset is different from the
>> defaut be the cause of the address being beyond the maximum?
>> (from the kernel config diff I sent before, changing the VMSPLIT
>> parameter, which gives the kernel 3GB of memory, causes the PAGE_OFFSET value to shift)

I have tried reproducing the problem by using your .config file on my
system just after you sent me it, but I cannot do it.


> worthk:~/makedumpfile-1.2.9$ patch -l -p1 --dry-run <v1.3.0-rc01.patch
> patching file Makefile
> Hunk #1 succeeded at 1 with fuzz 1.
> patching file ia64.c
> patching file makedumpfile-R.pl
> patching file makedumpfile.c
> patching file makedumpfile.h
> patching file x86.c
> patching file x86_64.c
> 
> The fuzz messages is because I'm patching against a makefile that was
> modified by Ubuntu to use "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"
> rather than "-D_FILE_OFFSET_BITS=64". Perhaps the difference between
> the Ubuntu version and this upstream setting should be resolved...
> Ubuntu changelog at https://launchpad.net/ubuntu/+source/makedumpfile
>  with note "Use _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE instead of
> _FILE_OFFSET_BITS=64 for correct compilation." Could this have negative
> effects or is it just a different way to tell the compiler to support
> large files?
> 
> CFLAGS = -g -O2 -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE \
>           -DVERSION='"$(VERSION)"' -DRELEASE_DATE='"$(DATE)"'
> CFLAGS_ARCH     = -g -O2 -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

I will consider it.


> On to the actual testing- I wonder if I am worse off than before applying this patch...
> 
> With command line "makedumpfile -D -E -d 31 -I $rootmnt/boot/vmcoreinfo /proc/vmcore $rootmnt/var/crash/vmcore"
> I get what appears to be a regression in check_release:
> 
> readmem: Can't convert a virtual address(403c1364) to physical address.
> check_release: Can't get the address of system_utsname.
> LOAD (0)
>   phys_start : 0
>   phys_end   : a0000
>   virt_start : c0000000
>   virt_end   : c00a0000
> LOAD (1)
>   phys_start : 100000
>   phys_end   : 1000000
>   virt_start : c0100000
>   virt_end   : c1000000
> LOAD (2)
>   phys_start : 5000000
>   phys_end   : 38000000
>   virt_start : c5000000
>   virt_end   : f8000000
> LOAD (3)
>   phys_start : 38000000
>   phys_end   : bf790000
>   virt_start : ffffffffffffffff
>   virt_end   : 8778ffff
> LOAD (4)
>   phys_start : 100000000
>   phys_end   : 140000000
>   virt_start : ffffffffffffffff
>   virt_end   : 3fffffff
> Linux kdump
> 
> max_mapnr    : 140000
> 
> PAE          : ON
> 
> makedumpfile Failed.
> 
> 
> If I change the command line to "makedumpfile -D -E -d 1 -I $rootmnt/boot/vmcoreinfo /proc/vmcore $rootmnt/var/crash/vmcore" (simply turn "-d" down to 1) I get
> 
> Excluding zero pages               : [ 33 %] readmem: Can't seek the dump memory(/proc/vmcore). Invalid argument
> create_2nd_bitmap: Can't exclude pages filled with zerocreate_2nd_bitmap: for creating an ELF dumpfile.

I guess that you don't apply v1.3.0-rc01.patch, because new error messages
of v1.3.0-rc01.patch are not printed in the above log.
If applying it, the below ~~~ messages should be printed.

readmem: Can't seek the dump memory(/proc/vmcore). (offset:XXX) Invalid argument
                                                   ~~~~~~~~~~~~
exclude_zero_pages: Can't get the page data(pfn:YYY, max_mapnr:ZZZ)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can confirm makedumpfile's version by `makedumpfile -v` like
the following:
  # makedumpfile -v
  makedumpfile: version 1.3.0-rc01 (released on 26 September 2008)
  
  #


Thanks
Ken'ichi Ohmichi