Re: [Crash-utility] [help]crash can't anaylyse xen guest paravirtulized linux vmcore

Date: Thu, 27 Oct 2011 09:34:56 -0400 From: anderson(a)redhat.com To: crash-utility(a)redhat.com Subject: Re: [Crash-utility] [help]crash can't anaylyse xen guest paravirtulized linux vmcore ----- 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(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility