Of course the issues seemed to have regressed... I took the makedumpfile 1.2.9 source, then tested applying the patch with "--dry-run" but forgot to actually apply it! :X I now get the following result (still a failure but hopefully provides some additional info). As I mentioned before, I have another system with identical hardware but only 2GB of memory instead of 4GB and I don't encounter this, not sure what kind of system you're testing on, but it may not reproduce with <4GB of memory, despite having a matching config. -Kevin Excluding zero pages : [ 38 %] readmem: Can't seek the dump memory(/proc/vmcore). (offset:800002d8) Invalid argument readmem: addr:84060000, size:4096 exclude_zero_pages: Can't get the page data(pfn:84060, max_mapnr:140000). create_2nd_bitmap: Can't exclude pages filled with zero for creating an ELF dumpfile. 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 mem_map (0) mem_map : 0 pfn_start : 0 pfn_end : 140000 makedumpfile Failed. -----Original Message----- From: Ken'ichi Ohmichi [mailto:oomichi@xxxxxxxxxxxxxxxxx] Sent: Sunday, September 28, 2008 9:19 PM To: Worth, Kevin Cc: Masaki Tachibana; kexec-ml Subject: Re: Problems writing ELF dumps with makedumpfile 1.2.9 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
