All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Anand <panand@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	catalin.marinas@arm.com, will.deacon@arm.com, vgoyal@redhat.com,
	hbabus@us.ibm.com
Cc: linaro-kernel@lists.linaro.org, geoff@infradead.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	broonie@kernel.org, david.griego@linaro.org,
	linux-arm-kernel@lists.infradead.org,
	Dave Young <dyoung@redhat.com>
Subject: Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Fri, 10 Apr 2015 12:05:58 +0530	[thread overview]
Message-ID: <55276F4E.3010103@redhat.com> (raw)
In-Reply-To: <5527663A.70402@linaro.org>



On Friday 10 April 2015 11:27 AM, AKASHI Takahiro wrote:
> Hi Pratyush,
>
> On 04/09/2015 10:09 PM, Pratyush Anand wrote:
>> Hi Takahiro,
>>
>> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
>>> Crash dump kernel will access memory regions in system kernel via
>>> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
>>> such pages are not part of main memory of crash dump kernel.
>>> This is true under non-UEFI environment because kexec-tools modifies
>>> a device tree adding "usablemem" attributes to memory sections.
>>> Under UEFI, however, this is not true because UEFI remove memory
>>> sections
>>> in a device tree and export all the memory regions, even though they
>>> belong
>>> to system kernel.
>>>
>>> So we should add "mem=X[MG]" boot parameter to limit the meory size and
>>> avoid hitting the following assertion in ioremap():
>>>     if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>>>         return NULL;
>>
>> Well I am using your updated kexec-tool which has support of automatic
>> addition of "mem=" parameter. I found that this
>> warning is still appearing and therefore another error about "Kdump:
>> vmcore not initialized".
>>
>> Memory address for which ioremap failed was almost at the top of
>> crash_reserved_mem. So I modified kexec-tool [1] to
>> accept user specific mem= parameter with a value lesser than physical
>> location which was being remapped, however still
>> the warning was there.
>>
>> Further I noticed that there is no reserved memblock with nonzero
>> memblock_region->size when early_mem ->
>> memblock_enforce_memory_limit is called. Therefore this mem= param is
>> not limiting memory location in my case.
>
> On crash dump kernel? Sounds strange.
> Can you send me the followings for both 1st kernel and crash dump kernel?
> (add memblock_debug to cmd line for verbose messages)
>
> - boot log (dmesg)
> - cat /proc/iomem
>
> sending them in a private mail is fine.

OK.

>
>> I was just wondering, why do not we use ioremap_cache instead of
>> ioremap in copy_oldmem_page?
>
> Good point.
> My next version of kdump patch uses ioremap_cache() for another reason.

Thanks that you have already changed it. I am using ioremap_cache and I 
am able to get /proc/vmcore :)
ioremap allocates VAs with memory attribute DEVICE which might not be 
correct for RAM area.ioremap_cache is using memory attribute NORMAL 
which seems more logical for RAM areas.

> # As I'm discussing with Mark about kvm issue, I'm holding off
> submitting it.
>

I  am using one more modification on top of your patches for finding 
crashkernel address automatically. If that seems fine to you then may be 
I can send you that patch and you can add that in your next rev.

Author: Pratyush Anand <panand@redhat.com>
Date:   Tue Apr 7 08:14:55 2015 +0530

     arm64/kdump: Find free area for crash kernel memory

     If crashkernel=X@0 is passed to the kernel then this patch will find
     free memory area of size X for crash kernel.

     Signed-off-by: Pratyush Anand <panand@redhat.com>

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 94694897beea..90b0b9d138f6 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -368,10 +368,18 @@ static void __init reserve_crashkernel(void)
         if (ret)
                 return;

-       ret = memblock_reserve(crash_base, crash_size);
-       if (ret < 0) {
+       /* 0 means: find the address automatically */
+       if (crash_base <= 0) {
+               crash_base = memblock_alloc(crash_size, 2 << 20);
+
+               if (!crash_base) {
+                       pr_warn("Could not find free memory for 
crashkernel\n");
+                       return;
+               }
+
+       } else if (memblock_reserve(crash_base, crash_size) < 0) {
                 pr_warn("crashkernel reservation failed - memory is in 
use (0x%lx)\n",
-                       (unsigned long)crash_base);
+                               (unsigned long)crash_base);
                 return;
         }

~Pratyush

WARNING: multiple messages have this Message-ID (diff)
From: panand@redhat.com (Pratyush Anand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Fri, 10 Apr 2015 12:05:58 +0530	[thread overview]
Message-ID: <55276F4E.3010103@redhat.com> (raw)
In-Reply-To: <5527663A.70402@linaro.org>



On Friday 10 April 2015 11:27 AM, AKASHI Takahiro wrote:
> Hi Pratyush,
>
> On 04/09/2015 10:09 PM, Pratyush Anand wrote:
>> Hi Takahiro,
>>
>> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
>>> Crash dump kernel will access memory regions in system kernel via
>>> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
>>> such pages are not part of main memory of crash dump kernel.
>>> This is true under non-UEFI environment because kexec-tools modifies
>>> a device tree adding "usablemem" attributes to memory sections.
>>> Under UEFI, however, this is not true because UEFI remove memory
>>> sections
>>> in a device tree and export all the memory regions, even though they
>>> belong
>>> to system kernel.
>>>
>>> So we should add "mem=X[MG]" boot parameter to limit the meory size and
>>> avoid hitting the following assertion in ioremap():
>>>     if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>>>         return NULL;
>>
>> Well I am using your updated kexec-tool which has support of automatic
>> addition of "mem=" parameter. I found that this
>> warning is still appearing and therefore another error about "Kdump:
>> vmcore not initialized".
>>
>> Memory address for which ioremap failed was almost at the top of
>> crash_reserved_mem. So I modified kexec-tool [1] to
>> accept user specific mem= parameter with a value lesser than physical
>> location which was being remapped, however still
>> the warning was there.
>>
>> Further I noticed that there is no reserved memblock with nonzero
>> memblock_region->size when early_mem ->
>> memblock_enforce_memory_limit is called. Therefore this mem= param is
>> not limiting memory location in my case.
>
> On crash dump kernel? Sounds strange.
> Can you send me the followings for both 1st kernel and crash dump kernel?
> (add memblock_debug to cmd line for verbose messages)
>
> - boot log (dmesg)
> - cat /proc/iomem
>
> sending them in a private mail is fine.

OK.

>
>> I was just wondering, why do not we use ioremap_cache instead of
>> ioremap in copy_oldmem_page?
>
> Good point.
> My next version of kdump patch uses ioremap_cache() for another reason.

Thanks that you have already changed it. I am using ioremap_cache and I 
am able to get /proc/vmcore :)
ioremap allocates VAs with memory attribute DEVICE which might not be 
correct for RAM area.ioremap_cache is using memory attribute NORMAL 
which seems more logical for RAM areas.

> # As I'm discussing with Mark about kvm issue, I'm holding off
> submitting it.
>

I  am using one more modification on top of your patches for finding 
crashkernel address automatically. If that seems fine to you then may be 
I can send you that patch and you can add that in your next rev.

Author: Pratyush Anand <panand@redhat.com>
Date:   Tue Apr 7 08:14:55 2015 +0530

     arm64/kdump: Find free area for crash kernel memory

     If crashkernel=X at 0 is passed to the kernel then this patch will find
     free memory area of size X for crash kernel.

     Signed-off-by: Pratyush Anand <panand@redhat.com>

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 94694897beea..90b0b9d138f6 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -368,10 +368,18 @@ static void __init reserve_crashkernel(void)
         if (ret)
                 return;

-       ret = memblock_reserve(crash_base, crash_size);
-       if (ret < 0) {
+       /* 0 means: find the address automatically */
+       if (crash_base <= 0) {
+               crash_base = memblock_alloc(crash_size, 2 << 20);
+
+               if (!crash_base) {
+                       pr_warn("Could not find free memory for 
crashkernel\n");
+                       return;
+               }
+
+       } else if (memblock_reserve(crash_base, crash_size) < 0) {
                 pr_warn("crashkernel reservation failed - memory is in 
use (0x%lx)\n",
-                       (unsigned long)crash_base);
+                               (unsigned long)crash_base);
                 return;
         }

~Pratyush

WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Anand <panand@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	catalin.marinas@arm.com, will.deacon@arm.com, vgoyal@redhat.com,
	hbabus@us.ibm.com
Cc: linaro-kernel@lists.linaro.org, geoff@infradead.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	broonie@kernel.org, david.griego@linaro.org,
	Dave Young <dyoung@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Fri, 10 Apr 2015 12:05:58 +0530	[thread overview]
Message-ID: <55276F4E.3010103@redhat.com> (raw)
In-Reply-To: <5527663A.70402@linaro.org>



On Friday 10 April 2015 11:27 AM, AKASHI Takahiro wrote:
> Hi Pratyush,
>
> On 04/09/2015 10:09 PM, Pratyush Anand wrote:
>> Hi Takahiro,
>>
>> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
>>> Crash dump kernel will access memory regions in system kernel via
>>> copy_oldmem_page(), which reads a page with ioremap'ing it assuming that
>>> such pages are not part of main memory of crash dump kernel.
>>> This is true under non-UEFI environment because kexec-tools modifies
>>> a device tree adding "usablemem" attributes to memory sections.
>>> Under UEFI, however, this is not true because UEFI remove memory
>>> sections
>>> in a device tree and export all the memory regions, even though they
>>> belong
>>> to system kernel.
>>>
>>> So we should add "mem=X[MG]" boot parameter to limit the meory size and
>>> avoid hitting the following assertion in ioremap():
>>>     if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
>>>         return NULL;
>>
>> Well I am using your updated kexec-tool which has support of automatic
>> addition of "mem=" parameter. I found that this
>> warning is still appearing and therefore another error about "Kdump:
>> vmcore not initialized".
>>
>> Memory address for which ioremap failed was almost at the top of
>> crash_reserved_mem. So I modified kexec-tool [1] to
>> accept user specific mem= parameter with a value lesser than physical
>> location which was being remapped, however still
>> the warning was there.
>>
>> Further I noticed that there is no reserved memblock with nonzero
>> memblock_region->size when early_mem ->
>> memblock_enforce_memory_limit is called. Therefore this mem= param is
>> not limiting memory location in my case.
>
> On crash dump kernel? Sounds strange.
> Can you send me the followings for both 1st kernel and crash dump kernel?
> (add memblock_debug to cmd line for verbose messages)
>
> - boot log (dmesg)
> - cat /proc/iomem
>
> sending them in a private mail is fine.

OK.

>
>> I was just wondering, why do not we use ioremap_cache instead of
>> ioremap in copy_oldmem_page?
>
> Good point.
> My next version of kdump patch uses ioremap_cache() for another reason.

Thanks that you have already changed it. I am using ioremap_cache and I 
am able to get /proc/vmcore :)
ioremap allocates VAs with memory attribute DEVICE which might not be 
correct for RAM area.ioremap_cache is using memory attribute NORMAL 
which seems more logical for RAM areas.

> # As I'm discussing with Mark about kvm issue, I'm holding off
> submitting it.
>

I  am using one more modification on top of your patches for finding 
crashkernel address automatically. If that seems fine to you then may be 
I can send you that patch and you can add that in your next rev.

Author: Pratyush Anand <panand@redhat.com>
Date:   Tue Apr 7 08:14:55 2015 +0530

     arm64/kdump: Find free area for crash kernel memory

     If crashkernel=X@0 is passed to the kernel then this patch will find
     free memory area of size X for crash kernel.

     Signed-off-by: Pratyush Anand <panand@redhat.com>

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 94694897beea..90b0b9d138f6 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -368,10 +368,18 @@ static void __init reserve_crashkernel(void)
         if (ret)
                 return;

-       ret = memblock_reserve(crash_base, crash_size);
-       if (ret < 0) {
+       /* 0 means: find the address automatically */
+       if (crash_base <= 0) {
+               crash_base = memblock_alloc(crash_size, 2 << 20);
+
+               if (!crash_base) {
+                       pr_warn("Could not find free memory for 
crashkernel\n");
+                       return;
+               }
+
+       } else if (memblock_reserve(crash_base, crash_size) < 0) {
                 pr_warn("crashkernel reservation failed - memory is in 
use (0x%lx)\n",
-                       (unsigned long)crash_base);
+                               (unsigned long)crash_base);
                 return;
         }

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2015-04-10  6:37 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26  8:28 [PATCH 0/5] arm64: add kdump support AKASHI Takahiro
2015-03-26  8:28 ` AKASHI Takahiro
2015-03-26  8:28 ` AKASHI Takahiro
2015-03-26  8:28 ` [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26 18:30   ` Geoff Levand
2015-03-26 18:30     ` Geoff Levand
2015-03-26 18:30     ` Geoff Levand
2015-03-27  4:43   ` Geoff Levand
2015-03-27  4:43     ` Geoff Levand
2015-03-27  4:43     ` Geoff Levand
2015-03-30  2:35     ` AKASHI Takahiro
2015-03-30  2:35       ` AKASHI Takahiro
2015-03-30  2:35       ` AKASHI Takahiro
2015-04-09 13:09   ` Pratyush Anand
2015-04-09 13:09     ` Pratyush Anand
2015-04-09 13:09     ` Pratyush Anand
2015-04-10  5:57     ` AKASHI Takahiro
2015-04-10  5:57       ` AKASHI Takahiro
2015-04-10  5:57       ` AKASHI Takahiro
2015-04-10  6:35       ` Pratyush Anand [this message]
2015-04-10  6:35         ` Pratyush Anand
2015-04-10  6:35         ` Pratyush Anand
2015-03-26  8:28 ` [PATCH 2/5] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28 ` [PATCH 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26 22:29   ` Geoff Levand
2015-03-26 22:29     ` Geoff Levand
2015-03-26 22:29     ` Geoff Levand
2015-03-30  3:21     ` AKASHI Takahiro
2015-03-30  3:21       ` AKASHI Takahiro
2015-03-30  3:21       ` AKASHI Takahiro
2015-03-26  8:28 ` [PATCH 4/5] arm64: add kdump support AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28 ` [PATCH 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-03-26  8:28   ` AKASHI Takahiro
2015-04-01 15:56 ` [PATCH 0/5] arm64: add kdump support Pratyush Anand
2015-04-01 15:56   ` Pratyush Anand
2015-04-01 15:56   ` Pratyush Anand
2015-04-01 23:27   ` AKASHI Takahiro
2015-04-01 23:27     ` AKASHI Takahiro
2015-04-01 23:27     ` AKASHI Takahiro
2015-04-02  4:58     ` Pratyush Anand
2015-04-02  4:58       ` Pratyush Anand
2015-04-02  4:58       ` Pratyush Anand
2015-04-02  5:37       ` AKASHI Takahiro
2015-04-02  5:37         ` AKASHI Takahiro
2015-04-02  5:37         ` AKASHI Takahiro
2015-04-02  6:01         ` Pratyush Anand
2015-04-02  6:01           ` Pratyush Anand
2015-04-02  6:01           ` Pratyush Anand
2015-04-02  7:48           ` AKASHI Takahiro
2015-04-02  7:48             ` AKASHI Takahiro
2015-04-02  7:48             ` AKASHI Takahiro

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=55276F4E.3010103@redhat.com \
    --to=panand@redhat.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david.griego@linaro.org \
    --cc=dyoung@redhat.com \
    --cc=geoff@infradead.org \
    --cc=hbabus@us.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.