----- 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
