|
SLES11:/opt/kdump # nm -Bn vmlinux | grep -e ffffffff806f7360 -e ffffffff80674690
ffffffff80674690 B phys_to_machine_mapping ffffffff806f7360 B max_pfn ffffffff806f7360 should be "end_pfn" or "max_pfn", you are right! > Date: Wed, 26 Oct 2011 11:54:42 -0400 > From: anderson@xxxxxxxxxx > To: crash-utility@xxxxxxxxxx > Subject: Re: [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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility |
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
