<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Dave Anderson wrote: <blockquote TYPE=CITE>Dave Anderson wrote: <blockquote TYPE=CITE>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 </blockquote> <tt>I'm still downloading the above, so I haven't been able</tt> <tt>to test it yet...</tt> <blockquote TYPE=CITE>... ---------------------------------------------------------------------------- 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. 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> </blockquote> <tt>This all sounds good, and I agree that the p2m_mfn should</tt> <tt>be added to the ia64 XEN_ELFNOTE_CRASH_INFO.</tt> <tt>However, there's something incorrect in your calculation of</tt> <tt>"xkd->p2m_frames" in your ia64_xen_kdump_p2m_create() implementation.</tt> <tt>It looks like it should be 32, but it's set to 524288. As a result</tt> <tt>that wastes a lot of memory, and "help -n" is pretty much unusable</tt> <tt>since wants to dump all ~512k entries:</tt> <tt>$ ./crash vmlinux-xen-ia64 vmcore.tiger.iomem_machine</tt> <tt>...</tt> <tt>crash> help -n</tt> <tt>...</tt> <tt> xen_kdump_data:</tt> <tt> flags: 5 (KDUMP_P2M_INIT|KDUMP_MFN_LIST)</tt> <tt> p2m_mfn: 1f62c</tt> <tt> cr3: 0</tt> <tt> last_mfn_read: 1fd09</tt> <tt> page: 6000000000c96bd0</tt> <tt> accesses: 1340</tt> <tt> cache_hits: 1255 (95%)</tt> <tt> p2m_frames: 524288</tt> <tt> p2m_mfn_frame_list: 200000000539c010</tt> <tt>1efba 1f5cc 1fd09 1e185 1d984 1d183 1c982 1c181 1b980 1b17f 1a97e 1a17d 1997c 1917b 1897a 18179 17978 17177 16976 16175 15974 15173 14972 14171 13970 1316f 1296e 1216d 1196c 1116b 1096a 10169 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 1efb8 1efb7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 1efb6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</tt> <tt>0 0 0 0 0 0 0</tt> <tt>If you enter "crash -d2", you'll also see all 512k, mostly useless,</tt> <tt>entries...</tt> </blockquote> <tt>Perhaps I am misunderstanding the reference you made with respect</tt> <tt>to the "machine memory layout is sparse"?</tt> <tt>In the other xen arches, the p2m_frame list reflects contiguous</tt> <tt>pseudo-physical memory, so I don't understand why, on your ia64</tt> <tt>sample dump which has 1GB of memory, that there would be more</tt> <tt>than 32 p2m frames?</tt> <tt>Each p2m frame would contain 2048 entries (given 16k pages).</tt> <tt>So with 32 p2m frames, that would account for 65536 pages,</tt> <tt>which equates to 1GB of pseudo-physical memory.</tt> <tt>Am I missing something?</tt> <tt>Dave</tt></blockquote> <tt>And finally...</tt><tt></tt> <tt>I don't understand what check_netdump_xen() and check_kdump_xen()</tt> <tt>are for. Both of them check whether "xen_kdump_data.p2m_mfn" has</tt> <tt>been initialized, and if so, they to initialize several things</tt> <tt>that should already have been initialized when xen_kdump_data.p2m_mfn</tt> <tt>was originally set?</tt> <tt> </tt> <tt>Are they ia64 only?</tt><tt></tt> <tt>Or are they *only* necessary for the strange case where the</tt> <tt>--p2m_mfn over-ride is used on that kludged-up netdump-to-kdump</tt> <tt>vmcore? I still don't understand how that dumpfile was even</tt> <tt>created -- should we even worry about that type of dumpfile</tt> <tt>even existing?</tt><tt></tt> <tt>Dave</tt> <tt></tt> <tt></tt> </html>