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
