----- Original Message ----- > Hi Dave, > > When parsing vmcore generated by ARM linux, Crash utility does > "phys to pfn" converting using this: > > " (paddr - machdep->machspec->phys_base) >> dd->block_shift;" > > First it minuses offset of the memory, and then does right shift. > But I glanced over kernel codes(2.6.34 - 3.15). I found nothing > to support the rationality of this type converting for ARM linux. > > And without this patch, the crash utility can not parse my vmcores. > > Also I can not get the commit messages because this code added before > crash-7.0.4. So, What's your purpose to introduce this? Is this patch > necessary for crash utility ? Or should I do some addtional work for > compatibility? > > (BTW,makedumpfile also has this type problem.) It's been that way since support for 32-bit ARM was first put in place almost four years ago: revision 1.26 date: 2010/08/27 17:25:07; author: anderson; state: Exp; lines: +39 -3 Introduction of ARM processor support for the crash utility. This is the result of collaborative effort between Nokia and Sony Ericsson. The crash utility can be built as a native ARM binary to analyze ARM dumpfiles or run live on an ARM host, or alternatively it can be built as an x86 binary to analyze ARM dumpfiles. To build crash as an ARM binary on an ARM host, enter "make" alone. To build crash as an x86 binary on an x86 host, enter "make target=ARM". By extension, the x86 binary can also be run on an x86_64 host. It supports kdump, and diskdump formats, and live using /dev/mem on ARM hosts. Stack unwinding support uses both frame pointers and ARM unwind tables. (ext-mika.1.westerberg@xxxxxxxxx, Jan.Karlsson@xxxxxxxxxxxxxxxx, Thomas.Fange@xxxxxxxxxxxxxxxx) And released in crash-5.0.7: http://people.redhat.com/anderson/crash.changelog.html#5_0_7 I have 3 sample compressed kdump ARM vmcores, all of which have are more recent than 2.6.34 and all of which have non-zero phys_base values that must be accounted for: RELEASE: 2.6.35-rc3-00272-gd189df4 phys_base: 80000000 RELEASE: 2.6.38-rc2-00274-g1f0324c-dirty phys_base: 80000000 RELEASE: 3.1.1 phys_base: c0000000 So obviously your patch is applied, they all fail to initialize, and it's unclear why your implementation would be different. I should note that support for 32-bit ARM was originally performed by the 3 authors above, and ongoing support has been done by them as well as several other key contributors on this mailing list. Dave > > Thanks, > Liu Hua > > Signed-off-by: Liu Hua <sdu.liu@xxxxxxxxxx> > --- > diskdump.c | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/diskdump.c b/diskdump.c > index e230c1f..1d72364 100644 > --- a/diskdump.c > +++ b/diskdump.c > @@ -914,15 +914,7 @@ page_is_cached(physaddr_t paddr) > static ulong > paddr_to_pfn(physaddr_t paddr) > { > -#ifdef ARM > - /* > - * In ARM, PFN 0 means first page in kernel direct-mapped view. > - * This is also first page in mem_map as well. > - */ > - return (paddr - machdep->machspec->phys_base) >> dd->block_shift; > -#else > return paddr >> dd->block_shift; > -#endif > } > > /* > -- > 1.9.0 > > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
