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

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(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility