Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1425246pxf; Fri, 9 Apr 2021 08:08:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+VQ0ALaUPxoOtEheMlOv6RCgcnPP4LZwwmjQ5x0+dmE/MJk2FrTuq708YZ0Fn4KeY9yBu X-Received: by 2002:a05:6402:5255:: with SMTP id t21mr18052101edd.91.1617980881064; Fri, 09 Apr 2021 08:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617980881; cv=none; d=google.com; s=arc-20160816; b=HXcXkxwUQxIFiORf8LtILw1dwq5byeju7Tgy37zZQ+9igixn0eVt190N+TxxTvvLuy TXdO45pNHtApMdci8WFLwvaXWT0UtzA9mQ2lPwykEZcMpguBDsfckjgXpeWFJyWYJHv+ 6oocybLApHFDofca4UgxZpD2MClUR1K71NonDz3dDtopnborpmvjS6VLqUNG/8dBC2R+ EQrjz0ZWZT3xMlM6Ui7PU5OLxcgzLc02cJ5Ce4tkEASPQatcJ2WVgnbteOdZ2HM35aAc f3ffpvth1IufMM3KVIUjxXuX0PQLYpddpDX7IcZ6WZP+5QgEh5cmJQ0yGrkqtiiq0XYl R+Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=1faUSdBujCjlkP0IdOchxAHO+AJ/eVU3YtZMT8bZ+ho=; b=UUQhazL6VzoNKkuUXnWD2hIu311aWphsKVIZm+TmohOTQcv4gyvcpIkP+uFPNfmoNB WI1VTpxlgzsbSYUANA6LEM0HD5VixnKOE5XYNWVQvVk5uy0EG3/tJEeZo06Tao8XcAtH Iuc6PSTd9bogn7t7POJV5y82dO8J6xswbjwt8A+cnBTkPoy4NOcq4jjLy5WUVuFVsi// kcZgb2FgeI+/n6XabEbitSm8FkRDZZdQ/fOG1zYb9L6qCcXjW0J9HzcqpirRAniE6dZV SIvZJv07UPZ2+G2KkM5VWdUA3ay0Vs6VDicBu+jvQvYhbci4BPbC42Jogpc84IBEmS0L /4Tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ob8zNz0Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t22si2022869ejj.746.2021.04.09.08.07.36; Fri, 09 Apr 2021 08:08:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ob8zNz0Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233970AbhDIPGq (ORCPT + 99 others); Fri, 9 Apr 2021 11:06:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233777AbhDIPGo (ORCPT ); Fri, 9 Apr 2021 11:06:44 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ED26C061760 for ; Fri, 9 Apr 2021 08:06:31 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id w4so2219909wrt.5 for ; Fri, 09 Apr 2021 08:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=1faUSdBujCjlkP0IdOchxAHO+AJ/eVU3YtZMT8bZ+ho=; b=Ob8zNz0YoKHSOOrXWol1ho7ext2QDE2EWKrsVNjRsi1vKs0rvES3fIixiP2eO37uGb 9OB6afmfW3dEeUYks/3FuPJCGgZ91mqOkH+cjUhDDad3/mrXVvOBoJ88BUXka2fuIgVn YiqpgAQaItYf+/JBXG4WyBNOdAAubwdWttEd9q+0yaNBA0yhPVry18Zn6UBcw7Akjg30 oxdnvq2geIouwBiONz6Ok+d62peQjcvVhazHo7iItzFgLXoZRaGUHgspPGuQJcFUNRyu 7+vOF6AW++FL2yYCwin5bjshzhV+ArXQrX7X4x1XX3m/EXPQfxgX8xgeAJYkV4AvwZp9 gmTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=1faUSdBujCjlkP0IdOchxAHO+AJ/eVU3YtZMT8bZ+ho=; b=d9mLmeyHXqpVWGu3yuLeZOOO2nM04TJs2ZNwlH5lnqFSGGfnTf1Bn6uN3OAvIbUsp1 8/W5/bcNHWMmOQkOvpGmKNmO0DomaHxT5zOpjI+SpPrCyAnz3GZkIr4fxNMkXzKF5+Qx TN5wdgrBSMUBzFpp8jQU3GJcVPGK3ksohEsUkHFQeRSau7nymHf5Jyj1beWG6IFwhtc/ p5nn2WnhxF6LCsbE7W6CD/EWkCwL1/ol55NuSmmwiZUfhIzMCf0pBdmWaAukiwWVdUnm oUC7H7QajbyGK3rDaVBJiZ1DR174snMzCnPiSSnZIS0Nc+Yya0E/ypBRT5IkdTURu02e f+ag== X-Gm-Message-State: AOAM531esFRY6pMcItkQQUU5/Rnp1b8rdLKzMaM8QzoHZQNhfdAlkDup We0jWugSz8oeQcGith6scMo= X-Received: by 2002:adf:d211:: with SMTP id j17mr18574903wrh.311.1617980790006; Fri, 09 Apr 2021 08:06:30 -0700 (PDT) Received: from Red ([2a01:cb1d:3d5:a100:264b:feff:fe03:2806]) by smtp.googlemail.com with ESMTPSA id o25sm6134652wmh.1.2021.04.09.08.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Apr 2021 08:06:29 -0700 (PDT) Date: Fri, 9 Apr 2021 17:06:27 +0200 From: Corentin Labbe To: Bruce Mitchell Cc: ebiederm@xmission.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: crashkernel reservation failed - No suitable area found on a cortina/gemini SoC Message-ID: References: <34ff1fcc-e9ee-02c2-b2a8-d98a24ce94c3@linux.vnet.ibm.com> <7a75028b-4495-cd51-6a32-59fcf6e0f166@linux.vnet.ibm.com> <291254c6-97e3-f5ba-dcee-77f8e4d25f9b@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le Fri, Apr 09, 2021 at 04:53:13PM +0200, Corentin Labbe a ?crit : > Le Wed, Apr 07, 2021 at 07:59:27AM -0700, Bruce Mitchell a ?crit : > > On 4/7/2021 07:48, Corentin Labbe wrote: > > > Le Wed, Apr 07, 2021 at 07:28:26AM -0700, Bruce Mitchell a ?crit : > > >> On 4/7/2021 07:23, Corentin Labbe wrote: > > >>> Le Wed, Apr 07, 2021 at 07:13:04AM -0700, Bruce Mitchell a ?crit : > > >>>> On 4/7/2021 05:54, Corentin Labbe wrote: > > >>>>> Hello > > >>>>> > > >>>>> I try to do kexec on a cortina/gemini SoC. > > >>>>> On a "normal" boot, kexec fail to find memory so I added crashkernel=8M to cmdline. (kernel size is ~6M). > > >>>>> But now, kernel fail to reserve memory: > > >>>>> Load Kern image from 0x30020000 to 0x800000 size 7340032 > > >>>>> Booting Linux on physical CPU 0x0 > > >>>>> Linux version 5.12.0-rc5-next-20210401+ (compile@Red) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r2 p4) 9.3.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #98 PREEMPT Wed Apr 7 14:14:08 CEST 2021 > > >>>>> CPU: FA526 [66015261] revision 1 (ARMv4), cr=0000397f > > >>>>> CPU: VIVT data cache, VIVT instruction cache > > >>>>> OF: fdt: Machine model: Edimax NS-2502 > > >>>>> Memory policy: Data cache writeback > > >>>>> Zone ranges: > > >>>>> Normal [mem 0x0000000000000000-0x0000000007ffffff] > > >>>>> HighMem empty > > >>>>> Movable zone start for each node > > >>>>> Early memory node ranges > > >>>>> node 0: [mem 0x0000000000000000-0x0000000007ffffff] > > >>>>> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] > > >>>>> crashkernel reservation failed - No suitable area found. > > >>>>> Built 1 zonelists, mobility grouping on. Total pages: 32512 > > >>>>> Kernel command line: console=ttyS0,19200n8 ip=dhcp crashkernel=8M > > >>>>> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) > > >>>>> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) > > >>>>> mem auto-init: stack:off, heap alloc:off, heap free:off > > >>>>> Memory: 119476K/131072K available (5034K kernel code, 579K rwdata, 1372K rodata, 3020K init, 210K bss, 11596K reserved, 0K cma-reserved, 0K highmem) > > >>>>> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > > >>>>> > > >>>>> What can I do ? > > >>>>> > > >>>>> Thanks > > >>>>> Regards > > >>>>> > > >>>>> _______________________________________________ > > >>>>> kexec mailing list > > >>>>> kexec@lists.infradead.org > > >>>>> http://lists.infradead.org/mailman/listinfo/kexec > > >>>>> > > >>>> > > >>>> Hello Corentin, > > >>>> > > >>>> I see much larger crashkernel=xxM being shown here > > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kdump/kdump.rst > > >>>> and from many of my other searches. > > >>>> > > >>>> Here is an interesting article on kdump for ARM-32 > > >>>> https://kaiwantech.wordpress.com/2017/07/13/setting-up-kdump-and-crash-for-arm-32-an-ongoing-saga/ > > >>>> > > >>>> > > >>>> Here is the kernel command line reference > > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v5.11#n732 > > >>>> > > >>>> I feel your frustrations too. > > >>> > > >>> Hello > > >>> > > >>> Thanks but I have already read those documentation. > > >>> I search to know why the kernel cannot find 8M of memory ouf of 128. > > >>> > > >>> Regards > > >>> > > >> > > >> How much more memory does the kernel and initrd above and beyond just > > >> their physical size? (heaps, stacks, buffers, virtual filesystems) > > > > > > The kernel size include a rootfs.cpio.lzma of 3MB and dtb is appended. > > > The total kernel size is 7MB. > > > The uncompressed size of the kernel is 13M (size of vmlinux) > > > The uncompressed size of rootfs is 11M. > > > > > > cat /proc/meminfo > > > MemTotal: 122496 kB > > > MemFree: 103700 kB > > > MemAvailable: 101936 kB > > > Buffers: 0 kB > > > Cached: 10904 kB > > > SwapCached: 0 kB > > > Active: 4304 kB > > > Inactive: 8012 kB > > > Active(anon): 4304 kB > > > Inactive(anon): 8012 kB > > > Active(file): 0 kB > > > Inactive(file): 0 kB > > > Unevictable: 0 kB > > > Mlocked: 0 kB > > > HighTotal: 0 kB > > > HighFree: 0 kB > > > LowTotal: 122496 kB > > > LowFree: 103700 kB > > > SwapTotal: 0 kB > > > SwapFree: 0 kB > > > Dirty: 0 kB > > > Writeback: 0 kB > > > AnonPages: 1428 kB > > > Mapped: 3552 kB > > > Shmem: 10904 kB > > > KReclaimable: 608 kB > > > Slab: 2960 kB > > > SReclaimable: 608 kB > > > SUnreclaim: 2352 kB > > > KernelStack: 312 kB > > > PageTables: 136 kB > > > NFS_Unstable: 0 kB > > > Bounce: 0 kB > > > WritebackTmp: 0 kB > > > CommitLimit: 61248 kB > > > Committed_AS: 14336 kB > > > VmallocTotal: 901120 kB > > > VmallocUsed: 64 kB > > > VmallocChunk: 0 kB > > > Percpu: 32 kB > > > CmaTotal: 0 kB > > > CmaFree: 0 kB > > > > > > > I believe you need space for all of that, > > the smallest that would work for me was 20MB. > > I tried without any change. > > Anyway when trying to kexec I got: > kexec --no-ifdown --command-line="console=ttyS0,19200n8" /tmp/kernel | > Could not find a free area of memory of 0x668a8a bytes... > Cannot load /tmp/kernel > > So reserving 8M is enough according to what kexec said. > > So anyone know why the kernel cannot reserve 8M ? > Thanks It seems to be related to: arch/arm/kernel/setup.c:977 "The crash region must be aligned to 128MB to avoid" Hacking CRASH_ALIGN to 64 permit Linux to reserve 8M at boot. But kexec still fail after with the same reason. (Could not find a free area of memory of 0x668a8a bytes)