On Wed, 6 Feb 2013 16:01:08 +0900
Atsushi Kumagai <[email protected]> wrote:

> Hello Petr,
> 
> On Thu, 10 Jan 2013 09:48:51 +0900
> Atsushi Kumagai <[email protected]> wrote:
> 
> > Hello Petr,
> > 
> > On Wed, 19 Dec 2012 16:01:25 +0100
> > Petr Tesarik <[email protected]> wrote:
> > 
> > > V Mon, 19 Nov 2012 17:40:44 +0900
> > > Atsushi Kumagai <[email protected]> napsáno:
> > > 
> > > > Hello Petr,
> > > > 
> > > > On Wed, 14 Nov 2012 15:42:12 +0100
> > > > Petr Tesarik <[email protected]> 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

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to