<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
SLES11:/opt/kdump # nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690<br>ffffffff80674690 B phys_to_machine_mapping<br>ffffffff806f7360 B max_pfn<br><br>ffffffff806f7360 should be "end_pfn" or "max_pfn", you are right!<br><BR><br><BR><div>> Date: Wed, 26 Oct 2011 11:54:42 -0400<br>> From: anderson@redhat.com<br>> To: crash-utility@redhat.com<br>> Subject: Re: [Crash-utility] [help]crash can't anaylyse xen guest paravirtulized linux vmcore<br>> <br>> <br>> <br>> ----- Original Message -----<br>> > <br>> > <br>> > ----- Original Message -----<br>> > > <br>> > > <br>> > > SLES11:/opt/tar_rpm/crash-5.1.9 # ./crash -d8 /opt/kdump/vmlinux<br>> > > /opt/kdump/sles11_1.mem > /tmp/crash_output3<br>> > > <br>> > > <br>> > > output see attachement.<br>> > > <br>> > > <br>> > > <br>> > > Thank your response.<br>> > <br>> > It's been a long time since I've looked at the particulars of a Xen dumpfile<br>> > given that Red Hat has discontinued Xen for KVM, so I'm a bit rusty. In any<br>> > case, upon the first memory read, while trying to walk through the page table<br>> > data to resolve a kernel virtual address, it comes to a dead end. I have no<br>> > idea why, nor do I have any further suggestions.<br>> > <br>> > Can the SLES-qualified members of the list confirm that "xm dump" still creates<br>> > dumpfiles that crash can handle?<br>> > <br>> > Dave<br>> <br>> FWIW, it's actually making the second kernel virtual address read:<br>> <br>> $ grep pgd: crash_output3<br>> [ffffffff806f7360] pgd: 9af04067 mfn: 9af04 pgd_index: 1fe<br>> [ffffffff80674690] pgd: 9af04067 mfn: 9af04 pgd_index: 1fe<br>> $<br>> <br>> where, depending upon the kernel version, ffffffff806f7360 should<br>> be "end_pfn" or "max_pfn". It ended up resolving that first virtual<br>> address to a page table and page, but the data there doesn't make sense:<br>> <br>> $ grep "end pfn:" crash_output3<br>> end pfn: 0<br>> $<br>> <br>> So even though it appeared to work OK, it's apparently bogus.<br>> <br>> Then I believe that the second virtual address of ffffffff80674690<br>> should be "p2m_top", and while trying to walk the page tables for <br>> that virtual address, it failed.<br>> <br>> If you do this:<br>> <br>> $ nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690<br>> <br>> you can at least verify that. But unfortunately it doesn't really<br>> help understand what's happening.<br>> <br>> Dave<br>> <br>> --<br>> Crash-utility mailing list<br>> Crash-utility@redhat.com<br>> https://www.redhat.com/mailman/listinfo/crash-utility<br></div> </div></body>
</html>