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