<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Itsuro ODA wrote: <blockquote TYPE=CITE>Hi Dave, The attached patch enables to analyze dom0 linux from whole memory dump on IA64. (for crash-4.0-4.1) It is just quick hack. (I was asked from IA64 Xen developers and made it.) Each domain manages own machine memory by domain.arch.mm.pgd in IA64. It is 3-level page table. I thougnt the mfn of domain.arch.mm.pgd can be regarded as p2m_mfn. I intended to modify as less existent code as possible. But this patch is a bit tricky. And the memory usage is large if the machine memory layout is sparse. (maybe xen_kdump_p2m should be prepare for each arch ?) Would you consider to support dom0 analysis for IA64 ? I prepared two sample dumps. Please find from the following URLs. 1) <a href="http://people.valinux.co.jp/~oda/20070510-sample-dump-1.tar">http://people.valinux.co.jp/~oda/20070510-sample-dump-1.tar</a> contents: - vmcore.gz This is taken by a hard assist dump. netdump style ELF vmcore. So XEN_ELFNOTE_CRASH_INFO does not exist. - vmcore.ka.gz It is coverted to kdump style and added XEN_ELFNOTE_CRASH_INFO manually. - vmlinux.debug.gz for dom0 analysis - xen-syms-2.6.18-8.el5.gz for xencrash To get p2m_mfn, xencrash's doms command is usefull. -------------------------------------------------------------------------- # crash xen-syms-2.6.18-8.el5 vmcore ... crash> doms DID DOMAIN ST T MAXPAGE TOTPAGE VCPU SHARED_I P2M_MFN 32753 f000000007ac8080 RU O 0 0 0 0 ---- 32754 f000000007acc080 RU X 0 0 0 0 ---- > 32767 f000000007ff8080 RU I 0 0 4 0 ---- 0 f000000007aa4080 RU 0 10000 fc28 1 f000000007a88000 1abb7 >* 1 f000000007a78080 RU U 10603 10603 3 f000000007a5c000 1a909 crash> ---------------------------------------------------------------------------- Then normal crash session with --p2m_mfn option. ---------------------------------------------------------------------------- # crash --p2m_mfn=1abb7 vmlinux.debug vmcore ... ---------------------------------------------------------------------------- vmcore.ka has XEN_ELFNOTE_CRASH_INFO. so --p2m_mfn option not need. ---------------------------------------------------------------------------- # crash vmlinux.debug vmcore.ka ... ---------------------------------------------------------------------------- --p2m_mfn option is effective only if a vmcore has XEN_ELFNOTE_CRASH_INFO now. I think specifying --p2m_mfn option is regarded as the vmcore is XEN_CORE_DUMPFILE(). The patch supports this. I think it is necessary for dumps which does not have XEN_ELFNOTE_CRASH_INFO such as above sample. </blockquote> <tt>OK, I finally got these all downloaded. However, the xen-syms</tt> <tt>binary in the "sample-1" directory has no debug data:</tt><tt></tt> <tt># file xen-syms-2.6.18-8.el5</tt> <tt>xen-syms-2.6.18-8.el5: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically linked, stripped</tt> <tt>#</tt><tt></tt> <tt>And I see that check_netdump_xen() is only called if the</tt> <tt>netdump (?) vmcore is used, since it needs the --p2m_mfn</tt> <tt>argument. I have no idea where check_kdump_xen() would</tt> <tt>apply?</tt><tt></tt> <tt>In any case, I really prefer not to support whatever that</tt> <tt>first "hard assist dump. netdump style ELF" vmcore file.</tt> <tt>(What is that???)</tt><tt></tt> <tt>I don't see why the support for dom0 ia64 kdumps should</tt> <tt>be any different than for x86 and x86_64, both of which</tt> <tt>have XEN_ELFNOTE_CRASH_INFO notes containing the p2m mfn</tt> <tt>value.</tt> <tt>Therefore, the check_netdump_xen() and check_kdump_xen()</tt> <tt>can be thrown out, and all that is really required is the</tt> <tt>implementation of ia64_xen_kdump_p2m_create() for the vmlinux</tt> <tt>side. But it will still need a fix to deal with that</tt> <tt>over-sized (?) 512k p2m_frame list. Can you look into fixing</tt> <tt>that?</tt><tt></tt> <tt>Also, I don't quite understand the changes to xen_kdump_p2m().</tt> <tt>The first (generic) part is probably a safe thing to do:</tt><tt></tt> <tt>+ if (mfn_idx >= xkd->p2m_frames)</tt> <tt>+ return P2M_FAILURE;</tt><tt></tt> <tt>But if the above code is put into place, how would it</tt> <tt>be possible for the resultant mfn_frame to be 0?</tt><tt></tt> <tt>+ #ifdef IA64</tt> <tt>+ if (mfn_frame == 0)</tt> <tt>+ return P2M_FAILURE;</tt> <tt>+ #endif</tt><tt></tt> <tt>And I don't understand this part at all:</tt><tt></tt> <tt>+ #ifdef IA64</tt> <tt>+ if (!(*mfnptr & 0x1))</tt> <tt>+ return P2M_FAILURE;</tt> <tt>+ paddr = *mfnptr & _PFN_MASK;</tt> <tt>+ #else</tt> <tt>+ paddr = (physaddr_t)PTOB((ulonglong)(*mfnptr));</tt> <tt>+ #endif</tt><tt></tt> <tt>Although, after putting in a debug printf of what the mfns</tt> <tt>actually look like on an ia64, I guess I see why it's</tt> <tt>necessary.</tt><tt></tt> <tt>On x86 and x86_64, the mfnptr points to a simple mfn value.</tt><tt></tt> <tt>But on the ia64, I see mfns that look like 81000007bf3c761,</tt> <tt>where the "1-bit" is always set. And you don't shift the</tt> <tt>mfn value like x86/x86_64 do. Can you help me understand</tt> <tt>the format of the ia64 mfns? In other words, what part of a</tt> <tt>value such as 81000007bf3c761 is the actual mfn? Are there</tt> <tt>page flags or something in the lower bits of the number?</tt><tt></tt> <tt>Thanks,</tt> <tt> Dave</tt> <blockquote TYPE=CITE> 2) <a href="http://people.valinux.co.jp/~oda/20070510-sample-dump-2.tar">http://people.valinux.co.jp/~oda/20070510-sample-dump-2.tar</a> contents: - vmcore.tiger.iomem_machine.gz taken by Xen kdump - vmlinux-xen-ia64.bz2 - xen-syms-ia64.bz2 I asked Xen kdump developper (simon@valinux) to add "p2m_mfn" to XEN_ELFNOTE_CRASH_INFO. So this change of Xen kdump is not open yet. If this is OK for crash, it will be commited. Thanks. -- Itsuro ODA <oda@valinux.co.jp> ------------------------------------------------------------------------------------------------------------------------ Name: diff-20070510 diff-20070510 Type: unspecified type (application/octet-stream) Encoding: base64 ------------------------------------------------------------------------------------------------------------------------ -- Crash-utility mailing list Crash-utility@redhat.com <a href="https://www.redhat.com/mailman/listinfo/crash-utility">https://www.redhat.com/mailman/listinfo/crash-utility</a></blockquote> </html>