----- Original Message -----
my crash can analyse xen hvm guest linux memory dump core :
SLES11:/mnt/sles10.2_crash # crash32 -s vmlinux-debug sles10.img
WARNING: kernel version inconsistency between vmlinux and dumpfile
crash32> bt
PID: 0 TASK: c02d8280 CPU: 0 COMMAND: "swapper"
#0 [c0329f9c] schedule at c0288d6d
#1 [c0329ffc] is386 at c0100194
OK, so you're saying that it's only an issue with SLES paravirtualized
kernels?
I compared the output of "crash -d8" output using a 2.6.18-152.el5xen kernel
(fully virtualized with the old Xen patch), and the sequence is pretty
much identical, other than the .xen_p2m and .xen_pages Elf64_Shdr's are
in a different order in the dumpfile. But that shouldn't make a difference,
because crash doesn't expect them in any particular order.
So again, the only thing I can see is that the page that contains the
"max_pfn" symbol is full of zeroes -- which is obviously wrong -- and
then while walking the page tables to find the page containing the
"phys_to_machine_mapping" symbol, it finds the page table that should
contain a PTE that points to the page containing it, but the PTE entry
is zero. Although other PTEs in the page table page do contain legitimate
PTEs.
The only thing I can think of is that the vmlinux file that you're using
doesn't match the dumpfile, i.e., the "max_pfn" and
"phys_to_machine_mapping"
symbols from the vmlinux file are not the same as the kernel represented by
the dumpfile?
Dave