> 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