On Wed, 6 Feb 2013 16:01:08 +0900 Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote: > Hello Petr, > > On Thu, 10 Jan 2013 09:48:51 +0900 > Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote: > > > Hello Petr, > > > > On Wed, 19 Dec 2012 16:01:25 +0100 > > Petr Tesarik <ptesarik at suse.cz> wrote: > > > > > V Mon, 19 Nov 2012 17:40:44 +0900 > > > Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> naps?no: > > > > > > > Hello Petr, > > > > > > > > On Wed, 14 Nov 2012 15:42:12 +0100 > > > > Petr Tesarik <ptesarik at suse.cz> wrote: > > > > > > > > > > Sorry for the late reply. > > > > > > According to your measurement, it looks good on performance. > > > > > > > > > > > > However, I found the issue below in v1.5.1-beta and made sure > > > > > > that this patch causes it by git bisect (but I don't find the > > > > > > true cause yet). > > > > > > > > > > > > result on kernel 3.4: > > > > > > $ makedumpfile --non-cyclic vmcore dumpfile > > > > > > Copying data : [ 62 %] > > > > > > readpage_elf: Can't convert a physical address(a0000) to \ > > > > > > offset. readmem: type_addr: 1, addr:1000a0000, size:4096 > > > > > > read_pfn: Can't get the page data. > > > > > > > > > > > > makedumpfile Failed. > > > > > > $ > > > > > > > > > > > > It seems critical issue for all users, so I will postpone merging > > > > > > this patch until this issue is solved. > > I found the cause of this issue. > > In the log above, readmem() try to read 0x1000a0000 (and it's correct), > but readpage_elf() try to read 0xa0000. > This is because your code uses PAGEBASE macro before readpage_elf(). > > #define PAGEBASE(X) (((unsigned long)(X)) & ~(PAGESIZE() - 1)) > > In 32bit systems, sizeof(unsigned long) is 32, 0x1000a0000 is truncated > to 0xa0000 and readpage_elf() gets it. > > It's PAGEBASE macro's issue, there is no problem in your code. > So, I'll merge your patch just as it is, and merge the patch below. Oh, this is great news! Thank you for the work, and sorry for my late reply. Petr Tesarik
