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

[Jay Lan]

Dave Anderson wrote:
> 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.

I found a patch posted by Jonathan Lim to the fastboot list in
March 2007:
https://lists.linux-foundation.org/pipermail/fastboot/2007-March/013645.html

I applied his patch to kexec-tools-testing-20080227 and it indeed
fixed the problem on IA64.

But Magnum Dammn came back with a revised patch and had some
discussion exchange with Vivek on the thread. Unfortunately,
Magnum since then did not work on kexec/kdump any more before
a final version was agreed upon.

- jay

> 
> 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
> 
> 
> 
> 
> 
> 
> 
> -- 
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility