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