[Crash-utility] [PATCH] crash: ARM: fix bug on paddr_to_pfn converting

[Dave Anderson]

----- 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 at nokia.com, Jan.Karlsson at sonyericsson.com,
   Thomas.Fange at sonyericsson.com)

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 at huawei.com>
> ---
>  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
>
>