----- Original Message ----- > Hi HATAYAMA, > > On Tue, Feb 14, 2012 at 9:37 AM, HATAYAMA Daisuke > <d.hatayama@xxxxxxxxxxxxxx> wrote: > > From: Lei Wen <adrian.wenl@xxxxxxxxx> > > Subject: Re: [PATCH] add arm support for libgcore > > Date: Mon, 13 Feb 2012 17:03:02 +0800 > > > >> Hi Hatayama, > >> > >> On Mon, Feb 13, 2012 at 4:33 PM, HATAYAMA Daisuke > >> <d.hatayama@xxxxxxxxxxxxxx> wrote: > >>> Hello Lei, > >>> > >>> Thanks for making patch. I'll check your patch this week, but I have > >>> two things to ask you. > >>> > >>> 1. I don't know arm architecture at all and I don't have arm > >>> machine. What I can do is only testing common part and regression test > >>> on x86 architecture. Please maintain arm part yourself. > >> > >> Sure, it is my pleasure. :) > >> > >>> > >>> 2. Could you tell me specific kernel versions you have tested this > >>> patch in? I myself have yet to do this, but now I think it necessary > >>> to make such a list. I imagine just like makedumpfile's SUPPORTED > >>> KERNELS described in its README. I'll put them in gcore's README and > >>> then ask Dave to add them into description in distribution page. > >> > >> I am current testing with kernel 2.6.35.7 and 3.0.8, and they are both ok. > > > > I see. > > > >> But I see below warnings during extracting, while the extracted core > >> dump image is OK for gdb, I don't know whether it there is still some missing in > >> original implementation, or those pages just don't existed in memory? > >> > >> gcore: PT_LOAD[165]: af900000 - af90e000 > >> gcore: WARNING: page fault at af909000 > >> gcore: WARNING: page fault at af90d000 > > > > These are verbose messages, which you can specify which to display via > > -v option. Please see help message in detail. However, important is > > "page fault" message below. > > > >> gcore: WARNING: page fault at af909000 > >> gcore: WARNING: page fault at af90d000 > > > > Most of crash dump mechanism doesn't collect swap space, such as > > kdump, diskdump, so in essence, crash gcore doesn't try to collect > > such paged-out user-space memory. > > > > crash gcore instead fills the paged-out memory with zero; this > > is easier implementation than reconstracting program headers. > > > > The reason why I've included the ``page fault'' in the default warning > > message is to avoid the situation where users get confused they have > > successfully got complete user-space coredump. > > > > GDB tends to work well because part of user stack necessary for > > backtrace is not paged out most of time; of course, the backtrace > > would fail if paged-out. > > > > Thanks. > > HATAYAMA, Daisuke > > > > I see, thanks for detailed explanation. > My another curious is whether we could refill those missing swapped page, if > we provide whole swap partition data? > > Thanks, > Lei Aren't most of those "page fault" references that you see during a gcore operation typically referring to pages that exist in the target task's virtual memory map but have not been referenced? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
