linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

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

Thread overview: 20+ 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 ` [PATCH 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-03-26 18:30   ` Geoff Levand
2015-03-27  4:43   ` Geoff Levand
2015-03-30  2:35     ` AKASHI Takahiro
2015-04-09 13:09   ` Pratyush Anand
2015-04-10  5:57     ` AKASHI Takahiro
2015-04-10  6:35       ` Pratyush Anand [this message]
2015-03-26  8:28 ` [PATCH 2/5] arm64: kdump: implement machine_crash_shutdown() 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 22:29   ` Geoff Levand
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 ` [PATCH 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-04-01 15:56 ` [PATCH 0/5] arm64: add kdump support Pratyush Anand
2015-04-01 23:27   ` AKASHI Takahiro
2015-04-02  4:58     ` Pratyush Anand
2015-04-02  5:37       ` AKASHI Takahiro
2015-04-02  6:01         ` Pratyush Anand
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=linux-arm-kernel@lists.infradead.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).