Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 11 Nov 2018 12:35:53 +0100
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
In-Reply-To: <1A7E2E89-34DB-41A0-BBA2-323073A7E298@gmx.us>
References: <1A7E2E89-34DB-41A0-BBA2-323073A7E298@gmx.us>
MIME-Version: 1.0
Message-Id: <20181111123553.3a35a15c@mschwideX1>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.