From patchwork Fri Apr 10 06:35:58 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pratyush Anand X-Patchwork-Id: 6192161 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C1E0C9F2E9 for ; Fri, 10 Apr 2015 06:40:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D4E882037A for ; Fri, 10 Apr 2015 06:40:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A2F8F2035E for ; Fri, 10 Apr 2015 06:40:01 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YgSYw-0008Qc-0E; Fri, 10 Apr 2015 06:37:10 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1YgSYo-0008B5-Gb; Fri, 10 Apr 2015 06:37:03 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3A6a6AV023303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 10 Apr 2015 02:36:07 -0400 Received: from localhost.localdomain (vpn-53-127.rdu2.redhat.com [10.10.53.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3A6ZxGB016088; Fri, 10 Apr 2015 02:36:00 -0400 Message-ID: <55276F4E.3010103@redhat.com> Date: Fri, 10 Apr 2015 12:05:58 +0530 From: Pratyush Anand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: AKASHI Takahiro , catalin.marinas@arm.com, will.deacon@arm.com, vgoyal@redhat.com, hbabus@us.ibm.com Subject: Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel References: <1427358533-3754-1-git-send-email-takahiro.akashi@linaro.org> <1427358533-3754-2-git-send-email-takahiro.akashi@linaro.org> <55267A23.2040007@redhat.com> <5527663A.70402@linaro.org> In-Reply-To: <5527663A.70402@linaro.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150409_233702_639230_4B1934EA X-CRM114-Status: GOOD ( 22.76 ) X-Spam-Score: -5.0 (-----) Cc: linaro-kernel@lists.linaro.org, geoff@infradead.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, broonie@kernel.org, david.griego@linaro.org, Dave Young , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Friday 10 April 2015 11:27 AM, AKASHI Takahiro wrote: > Hi Pratyush, > > On 04/09/2015 10:09 PM, Pratyush Anand wrote: >> Hi Takahiro, >> >> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote: >>> Crash dump kernel will access memory regions in system kernel via >>> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that >>> such pages are not part of main memory of crash dump kernel. >>> This is true under non-UEFI environment because kexec-tools modifies >>> a device tree adding "usablemem" attributes to memory sections. >>> Under UEFI, however, this is not true because UEFI remove memory >>> sections >>> in a device tree and export all the memory regions, even though they >>> belong >>> to system kernel. >>> >>> So we should add "mem=X[MG]" boot parameter to limit the meory size and >>> avoid hitting the following assertion in ioremap(): >>> if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) >>> return NULL; >> >> Well I am using your updated kexec-tool which has support of automatic >> addition of "mem=" parameter. I found that this >> warning is still appearing and therefore another error about "Kdump: >> vmcore not initialized". >> >> Memory address for which ioremap failed was almost at the top of >> crash_reserved_mem. So I modified kexec-tool [1] to >> accept user specific mem= parameter with a value lesser than physical >> location which was being remapped, however still >> the warning was there. >> >> Further I noticed that there is no reserved memblock with nonzero >> memblock_region->size when early_mem -> >> memblock_enforce_memory_limit is called. Therefore this mem= param is >> not limiting memory location in my case. > > On crash dump kernel? Sounds strange. > Can you send me the followings for both 1st kernel and crash dump kernel? > (add memblock_debug to cmd line for verbose messages) > > - boot log (dmesg) > - cat /proc/iomem > > sending them in a private mail is fine. OK. > >> I was just wondering, why do not we use ioremap_cache instead of >> ioremap in copy_oldmem_page? > > Good point. > My next version of kdump patch uses ioremap_cache() for another reason. Thanks that you have already changed it. I am using ioremap_cache and I am able to get /proc/vmcore :) ioremap allocates VAs with memory attribute DEVICE which might not be correct for RAM area.ioremap_cache is using memory attribute NORMAL which seems more logical for RAM areas. > # As I'm discussing with Mark about kvm issue, I'm holding off > submitting it. > I am using one more modification on top of your patches for finding crashkernel address automatically. If that seems fine to you then may be I can send you that patch and you can add that in your next rev. Author: Pratyush Anand Date: Tue Apr 7 08:14:55 2015 +0530 arm64/kdump: Find free area for crash kernel memory If crashkernel=X@0 is passed to the kernel then this patch will find free memory area of size X for crash kernel. Signed-off-by: Pratyush Anand } ~Pratyush diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 94694897beea..90b0b9d138f6 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -368,10 +368,18 @@ static void __init reserve_crashkernel(void) if (ret) return; - ret = memblock_reserve(crash_base, crash_size); - if (ret < 0) { + /* 0 means: find the address automatically */ + if (crash_base <= 0) { + crash_base = memblock_alloc(crash_size, 2 << 20); + + if (!crash_base) { + pr_warn("Could not find free memory for crashkernel\n"); + return; + } + + } else if (memblock_reserve(crash_base, crash_size) < 0) { pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n", - (unsigned long)crash_base); + (unsigned long)crash_base); return;