Received: by 10.223.176.5 with SMTP id f5csp1325848wra; Wed, 7 Feb 2018 17:24:28 -0800 (PST) X-Google-Smtp-Source: AH8x225oUh08e6PXP4r6ISnM2eiyjLk/SWvnZnOZJrrGrZ5lb83noiLN60SuCDhjw6G2329+dEXc X-Received: by 10.99.109.77 with SMTP id i74mr6502588pgc.380.1518053068368; Wed, 07 Feb 2018 17:24:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518053068; cv=none; d=google.com; s=arc-20160816; b=RYW929XY2dqN7abLfuKBqmIvB2moQ99IdhZj0N0GimMsJ/F7djzVzzgCPb0PEwVuos /E0umyx1cSBgoFhO/6Ll2r26HauwBuZEwYnaTk6KCk3sFfyJbVKIyEoZvfZOibFHyjKW SK2N62E8mwJp38pIEgwGiNF2MJZjCNxM3GpgDSJlmkbcxoWSdOQmHfkaabnIdVYnbCl6 QBlPkKv97IlGsaZo/RYcAJAof8t1G3Drx1v0e26V1T1Wv+WQAY0dns54YwCytIqFAXJj c5FPCIHhc/F/fWk+KeP7LOVIE729xXzY8Wgu7xmkmO8i27qVGps0qJNfw7gTRpl7otlG apbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=nmhIGSEmfaTzLghLD+ujOtNao9pG/1irKFCp+A0JmEo=; b=p1LFEsYddXUXhDG74+7tr6v7+qpk09ajb6ZQT72Fg3v1vUnzW7jSVAISoJnj4ZbtpE oTflVkEJBC1Nr9g76RdInz6FvkxOOd0XBbc+SbShDrxK4uGmgl+7ChxtVvBM3y/0nFCA IM54J31UN53kZ8eJHBJZZpSleHgCxWAMKMKQkpekz/aPLGZqGXAjfqjdrodfj4JnwA9f U9CjvsplXpBbeQrTShQk2r+iOm8BKcX2ivYKl5CT/97maNWtDmchp39Vom2lOhbVBrtH I3st4V68Uh2xE2fB5iq3WaDKOFwOuW0kV0CgDqx9JePW2+781XfJi0LI/h7K0k2x+VJP oI8A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j25si1666579pgn.600.2018.02.07.17.24.14; Wed, 07 Feb 2018 17:24:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbeBHBXe (ORCPT + 99 others); Wed, 7 Feb 2018 20:23:34 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53492 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750807AbeBHBXc (ORCPT ); Wed, 7 Feb 2018 20:23:32 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BAE034075171; Thu, 8 Feb 2018 01:23:31 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E578BDEEDF; Thu, 8 Feb 2018 01:23:25 +0000 (UTC) Date: Thu, 8 Feb 2018 09:23:23 +0800 From: Baoquan He To: Dou Liyang Cc: Takao Indoh , Peter Zijlstra , Greg Kroah-Hartman , Mike Galbraith , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andy Lutomirski , linux-mm@kvack.org, Thomas Gleixner , "Kirill A. Shutemov" , Linus Torvalds , Cyrill Gorcunov , "Kirill A. Shutemov" , Andrew Morton , Borislav Petkov , Dave Young , Ingo Molnar , Vivek Goyal Subject: Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y Message-ID: <20180208012323.GE30270@localhost.localdomain> References: <20180207104111.sljc62bgkggmtio4@node.shutemov.name> <1518000336.29698.1.camel@gmx.de> <20180207120827.GB30270@localhost.localdomain> <2945e12f-caab-b7e7-77e0-bd3971e784be@cn.fujitsu.com> <20180207122724.GC30270@localhost.localdomain> <0a2d5abe-3081-a784-dd85-70d34a0f60cc@cn.fujitsu.com> <20180207124519.GD30270@localhost.localdomain> <0988774f-9de0-b18f-1216-57d802502bb7@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0988774f-9de0-b18f-1216-57d802502bb7@cn.fujitsu.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 08 Feb 2018 01:23:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 08 Feb 2018 01:23:31 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/08/18 at 09:14am, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:45 PM, Baoquan He wrote: > > On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > > > > > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > > > Hi Baoquan, > > > > > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > > > Hi Kirill,Mike > > > > > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which contained > > > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the bug this patch > > > > > > > > > fixed? > > > > > > > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > OK, I may get the reason. kaslr is enabled, right? You can try to > > I add 'nokaslr' to disable the KASLR feature. ~~~added?? > > # cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b > ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 > > > disable kaslr and try them again. Because phys_base and kaslr_offset are > > got from vmlinux, while these are generated at compiling time. Just a > > guess. > > > > Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. > > > Thanks, > dou. > > > > > > > > > > > > > > Revert your two commits: > > > > > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop box though. > > > > > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two tests: > > > > > > > > > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, then > > > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > > > > > > ......It is OK > > > > > > > > > > > > > > 2) use cp as core_collector, do the same operation to get the vmcore file. > > > > > > > then use makedumpfile to do like above: > > > > > > > > > > > > > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > > > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give more > > > > > > debugging message. > > > > > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > > > > > the crash works well, It's so interesting. > > > > > > > > > > Thanks, > > > > > dou. > > > > > > > > > > The debugging message with '-D': > > > > > > > > And what's the debugging printing when trigger crash by sysrq? > > > > > > > > > > kdump: dump target is /dev/vda2 > > > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > > > [ 2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > > > kdump: saving vmcore-dmesg.txt > > > kdump: saving vmcore-dmesg.txt complete > > > kdump: saving vmcore > > > sadump: does not have partition header > > > sadump: read dump device as unknown format > > > sadump: unknown format > > > LOAD (0) > > > phys_start : 1000000 > > > phys_end : 2a86000 > > > virt_start : ffffffff81000000 > > > virt_end : ffffffff82a86000 > > > LOAD (1) > > > phys_start : 1000 > > > phys_end : 9fc00 > > > virt_start : ffff880000001000 > > > virt_end : ffff88000009fc00 > > > LOAD (2) > > > phys_start : 100000 > > > phys_end : 13000000 > > > virt_start : ffff880000100000 > > > virt_end : ffff880013000000 > > > LOAD (3) > > > phys_start : 33000000 > > > phys_end : 7ffd7000 > > > virt_start : ffff880033000000 > > > virt_end : ffff88007ffd7000 > > > Linux kdump > > > page_size : 4096 > > > > > > max_mapnr : 7ffd7 > > > > > > Buffer size for the cyclic mode: 131061 > > > > > > num of NODEs : 1 > > > > > > > > > Memory type : SPARSEMEM_EX > > > > > > mem_map (0) > > > mem_map : ffffea0000000000 > > > pfn_start : 0 > > > pfn_end : 8000 > > > mem_map (1) > > > mem_map : ffffea0000200000 > > > pfn_start : 8000 > > > pfn_end : 10000 > > > mem_map (2) > > > mem_map : ffffea0000400000 > > > pfn_start : 10000 > > > pfn_end : 18000 > > > mem_map (3) > > > mem_map : ffffea0000600000 > > > pfn_start : 18000 > > > pfn_end : 20000 > > > mem_map (4) > > > mem_map : ffffea0000800000 > > > pfn_start : 20000 > > > pfn_end : 28000 > > > mem_map (5) > > > mem_map : ffffea0000a00000 > > > pfn_start : 28000 > > > pfn_end : 30000 > > > mem_map (6) > > > mem_map : ffffea0000c00000 > > > pfn_start : 30000 > > > pfn_end : 38000 > > > mem_map (7) > > > mem_map : ffffea0000e00000 > > > pfn_start : 38000 > > > pfn_end : 40000 > > > mem_map (8) > > > mem_map : ffffea0001000000 > > > pfn_start : 40000 > > > pfn_end : 48000 > > > mem_map (9) > > > mem_map : ffffea0001200000 > > > pfn_start : 48000 > > > pfn_end : 50000 > > > mem_map (10) > > > mem_map : ffffea0001400000 > > > pfn_start : 50000 > > > pfn_end : 58000 > > > mem_map (11) > > > mem_map : ffffea0001600000 > > > pfn_start : 58000 > > > pfn_end : 60000 > > > mem_map (12) > > > mem_map : ffffea0001800000 > > > pfn_start : 60000 > > > pfn_end : 68000 > > > mem_map (13) > > > mem_map : ffffea0001a00000 > > > pfn_start : 68000 > > > pfn_end : 70000 > > > mem_map (14) > > > mem_map : ffffea0001c00000 > > > pfn_start : 70000 > > > pfn_end : 78000 > > > mem_map (15) > > > mem_map : ffffea0001e00000 > > > pfn_start : 78000 > > > pfn_end : 7ffd7 > > > mmap() is available on the kernel. > > > Copying data : [100.0 %] - eta: 0s > > > Writing erase info... > > > offset_eraseinfo: 9567fb0, size_eraseinfo: 0 > > > kdump: saving vmcore complete > > > > > > Thanks, > > > dou > > > > > > > > > > > > > [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > sadump: does not have partition header > > > > > sadump: read dump device as unknown format > > > > > sadump: unknown format > > > > > LOAD (0) > > > > > phys_start : 1000000 > > > > > phys_end : 2a86000 > > > > > virt_start : ffffffff81000000 > > > > > virt_end : ffffffff82a86000 > > > > > LOAD (1) > > > > > phys_start : 1000 > > > > > phys_end : 9fc00 > > > > > virt_start : ffff880000001000 > > > > > virt_end : ffff88000009fc00 > > > > > LOAD (2) > > > > > phys_start : 100000 > > > > > phys_end : 13000000 > > > > > virt_start : ffff880000100000 > > > > > virt_end : ffff880013000000 > > > > > LOAD (3) > > > > > phys_start : 33000000 > > > > > phys_end : 7ffd7000 > > > > > virt_start : ffff880033000000 > > > > > virt_end : ffff88007ffd7000 > > > > > Linux kdump > > > > > page_size : 4096 > > > > > > > > > > max_mapnr : 7ffd7 > > > > > > > > > > Buffer size for the cyclic mode: 131061 > > > > > The kernel version is not supported. > > > > > The makedumpfile operation may be incomplete. > > > > > > > > > > num of NODEs : 1 > > > > > > > > > > > > > > > Memory type : SPARSEMEM_EX > > > > > > > > > > mem_map (0) > > > > > mem_map : ffff88007ff26000 > > > > > pfn_start : 0 > > > > > pfn_end : 8000 > > > > > mem_map (1) > > > > > mem_map : 0 > > > > > pfn_start : 8000 > > > > > pfn_end : 10000 > > > > > mem_map (2) > > > > > mem_map : 0 > > > > > pfn_start : 10000 > > > > > pfn_end : 18000 > > > > > mem_map (3) > > > > > mem_map : 0 > > > > > pfn_start : 18000 > > > > > pfn_end : 20000 > > > > > mem_map (4) > > > > > mem_map : 0 > > > > > pfn_start : 20000 > > > > > pfn_end : 28000 > > > > > mem_map (5) > > > > > mem_map : 0 > > > > > pfn_start : 28000 > > > > > pfn_end : 30000 > > > > > mem_map (6) > > > > > mem_map : 0 > > > > > pfn_start : 30000 > > > > > pfn_end : 38000 > > > > > mem_map (7) > > > > > mem_map : 0 > > > > > pfn_start : 38000 > > > > > pfn_end : 40000 > > > > > mem_map (8) > > > > > mem_map : 0 > > > > > pfn_start : 40000 > > > > > pfn_end : 48000 > > > > > mem_map (9) > > > > > mem_map : 0 > > > > > pfn_start : 48000 > > > > > pfn_end : 50000 > > > > > mem_map (10) > > > > > mem_map : 0 > > > > > pfn_start : 50000 > > > > > pfn_end : 58000 > > > > > mem_map (11) > > > > > mem_map : 0 > > > > > pfn_start : 58000 > > > > > pfn_end : 60000 > > > > > mem_map (12) > > > > > mem_map : 0 > > > > > pfn_start : 60000 > > > > > pfn_end : 68000 > > > > > mem_map (13) > > > > > mem_map : 0 > > > > > pfn_start : 68000 > > > > > pfn_end : 70000 > > > > > mem_map (14) > > > > > mem_map : 0 > > > > > pfn_start : 70000 > > > > > pfn_end : 78000 > > > > > mem_map (15) > > > > > mem_map : 0 > > > > > pfn_start : 78000 > > > > > pfn_end : 7ffd7 > > > > > mmap() is available on the kernel. > > > > > Checking for memory holes : [100.0 %] | STEP > > > > > [Checking for memory holes ] : 0.000014 seconds > > > > > __vtop4_x86_64: Can't get a valid pte. > > > > > readmem: Can't convert a virtual address(ffff88007ffd7000) to physical > > > > > address. > > > > > readmem: type_addr: 0, addr:ffff88007ffd7000, size:32768 > > > > > __exclude_unnecessary_pages: Can't read the buffer of struct page. > > > > > create_2nd_bitmap: Can't exclude unnecessary pages. > > > > > Checking for memory holes : [100.0 %] \ STEP > > > > > [Checking for memory holes ] : 0.000006 seconds > > > > > Checking for memory holes : [100.0 %] - STEP > > > > > [Checking for memory holes ] : 0.000004 seconds > > > > > __vtop4_x86_64: Can't get a valid pte. > > > > > readmem: Can't convert a virtual address(ffff88007ffd7000) to physical > > > > > address. > > > > > readmem: type_addr: 0, addr:ffff88007ffd7000, size:32768 > > > > > __exclude_unnecessary_pages: Can't read the buffer of struct page. > > > > > create_2nd_bitmap: Can't exclude unnecessary pages. > > > > > > > > > > makedumpfile Failed. > > > > > > > > > > > > > > > > > > > > > > > > > ......It causes makedumpfile failed. > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > dou. > > > > > > > > > > > > > > > -Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec