<html> <head> <style></style> </head> <body class='hmmessage'><div dir='ltr'> Ok, I can continue to compile a vmlinux for testing. <div>> Date: Thu, 27 Oct 2011 09:34:56 -0400 > From: anderson@redhat.com > To: crash-utility@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@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility </div> </div></body> </html>