[Crash-utility] Anyone seen this problem or what did i miss?

[Dave Anderson]

Jay Lan wrote:
> I tested in a rhel5.1 root with:
>    2.6.24 kernel
>    kexec-tools-testing-20080227
>    crash-4.0-5.1
> 
> 
> Crash failed to initialize:
> 
> crash: read error: kernel virtual address: a0000001007f0868  type:
> "kernel_config_data"
> WARNING: cannot read kernel_config_data
> crash: read error: kernel virtual address: a000000100f370b0  type: "xtime"
> 
> Has anyone else seen this problem?
> 
> Thanks,
>  - jay

I'm not sure what may have changed in the ia64 world between
2.6.18 and 2.6.24, but here's some things you can look at.

The "kernel_config_data" and "xtime" reads are the very first
two read attempts on the dumpfile -- the first one allows the
session to continue, whereas the second is such that it's not
worth continuing.

At that point in time, only unity-mapped address references
are allowed, although the relocatable ia64 kernel does set
aside a 64MB region 5 address region for mapping the kernel
text and data (instead of using region 7 like the old days).

So crash has to make a decision upon each read as to whether a
region 5 address is: (1) in the mapped kernel region, or (2) is
a mapped vmalloc() address.  I think that's probably working OK,
because the read attempt first has to pass through this part
of ia64_VTOP() below, and you're not getting the "Unexpected..."
error message:

         /*
          *  Differentiate between a 2.6 kernel address in region 5 and
          *  a real vmalloc() address.
          */
         case KERNEL_VMALLOC_REGION:
                /*
                 * Real vmalloc() addresses should never be the subject
                 * of a VTOP() translation.
                 */
                 if (ia64_IS_VMALLOC_ADDR(vaddr) ||
                     (ms->kernel_region != KERNEL_VMALLOC_REGION))
                         return(error(FATAL,
                             "ia64_VTOP(%lx): unexpected region 5 address\n",
                                  vaddr));
                /*
                 *  If it's a region 5 kernel address, subtract the starting
                 *  kernel virtual address, and then add the base physical page.
                 */
                 paddr = vaddr - ms->kernel_start +
                         (ms->phys_start & KERNEL_TR_PAGE_MASK);
                 break;

So the "paddr" calculated here seems to be incorrect in your case.  So what
you want to see is what ms->kernel_start is (traditionally set to the symbol
value of "_stext"), and probably more importantly in your case, what
ms->phys_start was previously determined to be in ia64_calc_phys_start().

Dave