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