From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Qian Cai <cai@gmx.us>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: crashkernel=512M is no longer working on this aarch64 server
Date: Sun, 11 Nov 2018 12:35:53 +0100 [thread overview]
Message-ID: <20181111123553.3a35a15c@mschwideX1> (raw)
In-Reply-To: <1A7E2E89-34DB-41A0-BBA2-323073A7E298@gmx.us>
On Sat, 10 Nov 2018 23:41:34 -0500
Qian Cai <cai@gmx.us> wrote:
> It was broken somewhere between b00d209241ff and 3541833fd1f2.
>
> [ 0.000000] cannot allocate crashkernel (size:0x20000000)
>
> Where a good one looks like this,
>
> [ 0.000000] crashkernel reserved: 0x0000000008600000 - 0x0000000028600000 (512 MB)
>
> Some commits look more suspicious than others.
>
> mm: add mm_pxd_folded checks to pgtable_bytes accounting functions
> mm: introduce mm_[p4d|pud|pmd]_folded
> mm: make the __PAGETABLE_PxD_FOLDED defines non-empty
The intent of these three patches is to add extra checks to the
pgtable_bytes accounting function. If applied incorrectly the expected
result would be warnings like this:
BUG: non-zero pgtables_bytes on freeing mm: 16384
The change Linus worried about affects the __PAGETABLE_PxD_FOLDED defines.
These defines are used with #ifdef, #ifndef, and __is_defined() for the
new mm_p?d_folded() macros. I can not see how this would make a difference
for your iomem setup.
> # diff -u ../iomem.good.txt ../iomem.bad.txt
> --- ../iomem.good.txt 2018-11-10 22:28:20.092614398 -0500
> +++ ../iomem.bad.txt 2018-11-10 20:39:54.930294479 -0500
> @@ -1,9 +1,8 @@
> 00000000-3965ffff : System RAM
> 00080000-018cffff : Kernel code
> - 018d0000-020affff : reserved
> - 020b0000-045affff : Kernel data
> - 08600000-285fffff : Crash kernel
> - 28730000-2d5affff : reserved
> + 018d0000-0762ffff : reserved
> + 07630000-09b2ffff : Kernel data
> + 231b0000-2802ffff : reserved
> 30ec0000-30ecffff : reserved
> 35660000-3965ffff : reserved
> 39660000-396fffff : reserved
> @@ -127,7 +126,7 @@
> 7c5200000-7c520ffff : 0004:48:00.0
> 1040000000-17fbffffff : System RAM
> 13fbfd0000-13fdfdffff : reserved
> - 16fba80000-17fbfdffff : reserved
> + 16fafd0000-17fbfdffff : reserved
> 17fbfe0000-17fbffffff : reserved
> 1800000000-1ffbffffff : System RAM
> 1bfbff0000-1bfdfeffff : reserved
The easiest way to verify if the three commits have something to do with your
problem is to revert them and run your test. Can you do that please ?
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2018-11-11 11:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-11 4:41 crashkernel=512M is no longer working on this aarch64 server Qian Cai
2018-11-11 11:35 ` Martin Schwidefsky [this message]
2018-11-11 13:36 ` Qian Cai
2018-11-12 6:01 ` Martin Schwidefsky
2018-11-12 12:29 ` Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181111123553.3a35a15c@mschwideX1 \
--to=schwidefsky@de.ibm.com \
--cc=cai@gmx.us \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).