From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM: issue with memory reservation from DT
Date: Mon, 20 Oct 2014 13:48:52 -0700 [thread overview]
Message-ID: <54457534.5050607@codeaurora.org> (raw)
In-Reply-To: <544149CF.5080809@codeaurora.org>
On 10/17/2014 9:54 AM, Laura Abbott wrote:
> On 10/17/2014 3:21 AM, Grygorii Strashko wrote:
>> Hi Laura,
>>
>> As I mentioned in first e-mail I've 1G Mem node initially:
>> reg = <0x8 0x00000000 0x0 0x40000000>;
>>
>> and have memory reservation of 512M in the upper part of memory:
>> reserved-memory {
>> reg = <0x8 0x20000000 0x0 0x20000000>;
>>
>> then in sanity_check_meminfo() initial mem configuration calculated as
>> following:
>>
>> [ 0.000000] ======= memblock_limit=0x000000082f800000
>> arm_lowmem_limit=0x000000082f800000 vmalloc_limit=ef800000
>> high_memory=0x000000082f800000
>> and memblock.current_limit == arm_lowmem_limit=0x000000082f800000
>>
>> then in arm_memblock_init()->early_init_fdt_scan_reserved_mem() 512M
>> of memory removed
>> (not reserved!, because "no-map;" is defined).
>>
>> After that Kernel will have only 512M of accessible memory
>> memory[0x0] [0x00000800000000-0x0000081fffffff]
>>
>> I've checked of_reserved_mem.c and saw no issues there :(
>>
>
> Yes, I suspect the issue is not with of_reserved_mem.c and instead with
> sanity_check_meminfo in mmu.c . I'm still traveling so I'll probably
> take a look on Monday unless I find some time sooner.
>
I was able to reproduce a crash on my device by removing all highmem
as well. It looks like the logic assumes that lowmem limit will only
ever increase and not need to decrease. This seems like a limitation
of running with CONFIG_HIGHMEM on a system which doesn't actually
need highmem. This seems to have been the case even before the meminfo
removal as well. The following worked for me:
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 9f98cec..6696016 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1140,6 +1140,9 @@ void __init sanity_check_meminfo(void)
}
}
+ if (arm_lowmem_limit > memblock_end_of_DRAM())
+ arm_lowmem_limit = memblock_end_of_DRAM();
+
high_memory = __va(arm_lowmem_limit - 1) + 1;
/*
I'll turn this into an official patch for review if it fixes your
problem as well.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
next prev parent reply other threads:[~2014-10-20 20:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 17:18 ARM: issue with memory reservation from DT Grygorii Strashko
2014-10-15 17:50 ` Russell King - ARM Linux
2014-10-16 17:32 ` Grygorii Strashko
2014-10-17 9:10 ` Laura Abbott
2014-10-17 10:21 ` Grygorii Strashko
2014-10-17 16:54 ` Laura Abbott
2014-10-20 20:48 ` Laura Abbott [this message]
2014-10-21 17:01 ` Grygorii Strashko
2014-10-21 18:32 ` Laura Abbott
2014-10-17 11:36 ` Santosh Shilimkar
2014-10-21 17:02 ` Grygorii Strashko
2014-10-21 17:16 ` Russell King - ARM Linux
2014-10-24 18:16 ` Laura Abbott
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=54457534.5050607@codeaurora.org \
--to=lauraa@codeaurora.org \
--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).