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

Jay Lan wrote: 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