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
Date: Wed, 26 Oct 2011 11:54:42 -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 -----
>
>
> ----- Original Message -----
> >
> >
> > SLES11:/opt/tar_rpm/crash-5.1.9 # ./crash -d8 /opt/kdump/vmlinux
> > /opt/kdump/sles11_1.mem > /tmp/crash_output3
> >
> >
> > output see attachement.
> >
> >
> >
> > Thank your response.
>
> It's been a long time since I've looked at the particulars of a Xen
dumpfile
> given that Red Hat has discontinued Xen for KVM, so I'm a bit rusty. In any
> case, upon the first memory read, while trying to walk through the page table
> data to resolve a kernel virtual address, it comes to a dead end. I have no
> idea why, nor do I have any further suggestions.
>
> Can the SLES-qualified members of the list confirm that "xm dump" still
creates
> dumpfiles that crash can handle?
>
> Dave
FWIW, it's actually making the second kernel virtual address read:
$ grep pgd: crash_output3
[ffffffff806f7360] pgd: 9af04067 mfn: 9af04 pgd_index: 1fe
[ffffffff80674690] pgd: 9af04067 mfn: 9af04 pgd_index: 1fe
$
where, depending upon the kernel version, ffffffff806f7360 should
be "end_pfn" or "max_pfn". It ended up resolving that first virtual
address to a page table and page, but the data there doesn't make sense:
$ grep "end pfn:" crash_output3
end pfn: 0
$
So even though it appeared to work OK, it's apparently bogus.
Then I believe that the second virtual address of ffffffff80674690
should be "p2m_top", and while trying to walk the page tables for
that virtual address, it failed.
If you do this:
$ nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690
you can at least verify that. But unfortunately it doesn't really
help understand what's happening.
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility