From patchwork Wed Apr 23 17:09:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rob Herring X-Patchwork-Id: 4043171 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.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3C6089F387 for ; Wed, 23 Apr 2014 17:19:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5F7D920220 for ; Wed, 23 Apr 2014 17:19:57 +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 7A7A32021F for ; Wed, 23 Apr 2014 17:19:56 +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 1Wd0nl-0005ry-K6; Wed, 23 Apr 2014 17:17:41 +0000 Received: from mail-ie0-x236.google.com ([2607:f8b0:4001:c03::236]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wd0ni-0005nv-UT for linux-arm-kernel@lists.infradead.org; Wed, 23 Apr 2014 17:17:39 +0000 Received: by mail-ie0-f182.google.com with SMTP id y20so1225305ier.41 for ; Wed, 23 Apr 2014 10:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qePkESIeP8+hSLWpLyBEo1xL54qvj/IWvLdxOjIwmKM=; b=ubofbmhuGvP/E2OPuZS5P7vYwCDu8bYuFmBCE66NIgw1ZldUH5Wmr/zVePOPopFLS/ baegfXnGTMuOKCQIE7CkPbLvo9JCi8zyxc+TPeepA80BYr2v0jYYjkHRWezlWSqvrbcc hDPfna51m5zLw7b66ZdTz8uxW4oVthfT71pmrTf4uuX79vrUwgTVHLD6JneVUR53bGBr USgs3p4u54ycvXep629UMZYViLWtT3TjsnvInbaqG4RJDFccW7N/huKaXOwbNVM/jSLS R1/SBrA9JrA2QqJMMnT1mrAqKf+bH9ZLsGcuAvCT79b/OR95b24or4RhkrtcBUZ4bNWm Iq0w== MIME-Version: 1.0 X-Received: by 10.43.151.7 with SMTP id kq7mr2615019icc.78.1398272940497; Wed, 23 Apr 2014 10:09:00 -0700 (PDT) Received: by 10.43.83.65 with HTTP; Wed, 23 Apr 2014 10:09:00 -0700 (PDT) In-Reply-To: References: <132601cf5e89$94556a70$bd003f50$@gmail.com> Date: Wed, 23 Apr 2014 12:09:00 -0500 Message-ID: Subject: Re: kdump for ARM Linux? From: Rob Herring To: Andrew Nicholas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140423_101739_057551_124180AA X-CRM114-Status: GOOD ( 24.62 ) X-Spam-Score: 0.1 (/) Cc: "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 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=-2.4 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham 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 Wed, Apr 23, 2014 at 11:51 AM, Andrew Nicholas wrote: > > > > On Tue, Apr 22, 2014 at 6:36 PM, Rob Herring wrote: >> >> On Tue, Apr 22, 2014 at 7:18 PM, Andy Nicholas >> wrote: > > >> >> > Has this issue been addressed in any version of an ARM Linux kernel? Or, >> > is >> > there a work-around? If not, how does a crashdump file get generated >> > when/if >> > the kernel crashes or a driver faults? >> > >> >>> arch/arm/mm/ioremap.c:244 >> >>> /* >> >>> * Don't allow RAM to be mapped - this causes problems with >> > ARMv6+ >> >>> */ >> >>> if (WARN_ON(pfn_valid(pfn))) >> >>> return NULL; >> > >> > Thanks in advance for any help. >> >> This is on purpose as the comment says because 2 mappings of different >> types (of memory attributes) is undefined behavior on ARMv6+. RAM is >> normal memory type and mmio devices are device memory. This check >> could possibly be relaxed in the case the memory type is compatible >> with normal RAM mappings. Then perhaps ioremap_cache could be used on >> RAM for kdump. > > > Thanks. I'm not very familiar with this code-path and looking at the code it > seems one possibility is that pfn_valid() is returning false due to > misconfiguration > of the kernel. > > Considering that the -normal- kdump path to create the /proc/vmcore dumpfile > via > parse_crash_elf32_headers appears to use __arm_ioremap in order to copy the > old memory from the old (presumably crashed) kernel -- this means that no > one > with an ARMv7 platform has ever gotten a dumpfile via kdump? Why v7? I don't think kdump would work on any ARM platform since the pfn_valid check was added. I'm not too surprised as kexec/kdump seem to be rarely used in practice and frequently broken. Something like this is what I had in mind. Alternatively, avoiding ioremap entirely might be a better solution. I think kmap_atomic could be used instead of ioremap. diff --git a/arch/arm/kernel/crash_dump.c b/arch/arm/kernel/crash_dump.c index 5d1286d..1adca4e 100644 --- a/arch/arm/kernel/crash_dump.c +++ b/arch/arm/kernel/crash_dump.c @@ -39,7 +39,7 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf, if (!csize) return 0; - vaddr = ioremap(__pfn_to_phys(pfn), PAGE_SIZE); + vaddr = ioremap_cache(__pfn_to_phys(pfn), PAGE_SIZE); if (!vaddr) return -ENOMEM; diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c index f9c32ba..0cd30d6 100644 --- a/arch/arm/mm/ioremap.c +++ b/arch/arm/mm/ioremap.c @@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn, /* * Don't allow RAM to be mapped - this causes problems with ARMv6+ */ - if (WARN_ON(pfn_valid(pfn))) + if (WARN_ON(pfn_valid(pfn) && mtype != MT_DEVICE_CACHED)) return NULL; area = get_vm_area_caller(size, VM_IOREMAP, caller);