From patchwork Thu Apr 28 09:27:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Russell King X-Patchwork-Id: 8967251 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 05B1E9F441 for ; Thu, 28 Apr 2016 09:30:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 13E5D202A1 for ; Thu, 28 Apr 2016 09:30:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2575720268 for ; Thu, 28 Apr 2016 09:30:36 +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 1aviG1-0005El-V0; Thu, 28 Apr 2016 09:29:13 +0000 Received: from pandora.arm.linux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aviFx-0004lh-SB for linux-arm-kernel@lists.infradead.org; Thu, 28 Apr 2016 09:29:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arm.linux.org.uk; s=pandora-2014; h=Date:Sender:Message-Id:Content-Type:Content-Transfer-Encoding:MIME-Version:Subject:Cc:To:From:References:In-Reply-To; bh=8dN5tHGjvgCn9UVP4ucH6GTttRuITl6A/uobYaRAUbs=; b=Ztj15ZDsgo88YlVRCXjqbf3J3yDygFnzGwHQgQWCTw8cBvG7wwtR3iLq46FnufE43tyXESFypxwe3w563bBYZfrylgz3ZW41yeK/BFOwLOdwHD/VCVTUAVp4b6B/D/2f2Nk1m62dbZ98yAn/52pdg6rYZbkkbwWrbnQFZShlygA=; Received: from e0022681537dd.dyn.arm.linux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:45720 helo=rmk-PC.arm.linux.org.uk) by pandora.arm.linux.org.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aviEg-0004AD-1P; Thu, 28 Apr 2016 10:27:50 +0100 Received: from rmk by rmk-PC.arm.linux.org.uk with local (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aviEe-0000if-VZ; Thu, 28 Apr 2016 10:27:49 +0100 In-Reply-To: <20160428092644.GX19428@n2100.arm.linux.org.uk> References: <20160428092644.GX19428@n2100.arm.linux.org.uk> From: Russell King To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 01/12] ARM: kexec: fix crashkernel= handling MIME-Version: 1.0 Content-Disposition: inline Message-Id: Date: Thu, 28 Apr 2016 10:27:48 +0100 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160428_022911_249701_62FA3ADA X-CRM114-Status: GOOD ( 19.59 ) X-Spam-Score: -5.3 (-----) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org, linux-doc@vger.kernel.org, Pawel Moll , Jonathan Corbet , Ian Campbell , kexec@lists.infradead.org, Fenghua Yu , Haren Myneni , Rob Herring , Eric Biederman , Santosh Shilimkar , Kumar Gala , Vivek Goyal Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,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 When the kernel crashkernel parameter is specified with just a size, we are supposed to allocate a region from RAM to store the crashkernel. However, ARM merely reserves physical address zero with no checking that there is even RAM there. Fix this by lifting similar code from x86, importing it to ARM with the ARM specific parameters added. In the absence of any platform specific information, we allocate the crashkernel region from the first 512MB of physical memory. Update the kdump documentation to reflect this change. Signed-off-by: Russell King Reviewed-by: Pratyush Anand --- Documentation/kdump/kdump.txt | 13 +++---------- arch/arm/kernel/setup.c | 29 +++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 10 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index bc4bd5a44b88..88ff63d5fde3 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -263,12 +263,6 @@ been removed from the machine. crashkernel=:[,:,...][@offset] range=start-[end] -Please note, on arm, the offset is required. - crashkernel=:[,:,...]@offset - range=start-[end] - - 'start' is inclusive and 'end' is exclusive. - For example: crashkernel=512M-2G:64M,2G-:128M @@ -307,10 +301,9 @@ Boot into System Kernel on the memory consumption of the kdump system. In general this is not dependent on the memory size of the production system. - On arm, use "crashkernel=Y@X". Note that the start address of the kernel - will be aligned to 128MiB (0x08000000), so if the start address is not then - any space below the alignment point may be overwritten by the dump-capture kernel, - which means it is possible that the vmcore is not that precise as expected. + On arm, the use of "crashkernel=Y@X" is no longer necessary; the + kernel will automatically locate the crash kernel image within the + first 512MB of RAM if X is not given. Load the Dump-capture Kernel diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 139791ed473d..77b54c461c52 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -938,6 +938,13 @@ static int __init init_machine_late(void) late_initcall(init_machine_late); #ifdef CONFIG_KEXEC +/* + * The crash region must be aligned to 128MB to avoid + * zImage relocating below the reserved region. + */ +#define CRASH_ALIGN (128 << 20) +#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20)) + static inline unsigned long long get_total_mem(void) { unsigned long total; @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void) if (ret) return; + if (crash_base <= 0) { + unsigned long long crash_max = CRASH_ADDR_MAX; + if (crash_max > (u32)~0) + crash_max = (u32)~0; + crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max, + crash_size, CRASH_ALIGN); + if (!crash_base) { + pr_err("crashkernel reservation failed - No suitable area found.\n"); + return; + } + } else { + unsigned long long start; + + start = memblock_find_in_range(crash_base, + crash_base + crash_size, + crash_size, SECTION_SIZE); + if (start != crash_base) { + pr_err("crashkernel reservation failed - memory is in use.\n"); + return; + } + } + ret = memblock_reserve(crash_base, crash_size); if (ret < 0) { pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",