All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Laura Abbott <lauraa@codeaurora.org>,
	David Brown <davidb@codeaurora.org>,
	Daniel Walker <dwalker@fifo99.com>,
	Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rob Herring <robherring2@gmail.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Santosh Shilimkar <santosh.shilimkar@ti>
Subject: Re: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 18:08:51 +0200	[thread overview]
Message-ID: <53208693.0@ti.com> (raw)
In-Reply-To: <20140312133806.GH21483@n2100.arm.linux.org.uk>

On 03/12/2014 03:38 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 12, 2014 at 03:09:53PM +0200, Grygorii Strashko wrote:
>> Hi Russell,
>>
>> On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
>>> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>>>> memblock is now fully integrated into the kernel and is the prefered
>>>> method for tracking memory. Rather than reinvent the wheel with
>>>> meminfo, migrate to using memblock directly instead of meminfo as
>>>> an intermediate.
>>>>
>>>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>>>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
>>>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>>>
>>> Laura,
>>>
>>> This patch causes a bunch of platforms to no longer boot - imx6solo with
>>> 1GB of RAM boots, imx6q with 2GB of RAM doesn't.  Versatile Express doesn't.
>>>
>>> The early printk messages don't reveal anything too interesting:
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #630 SMP Wed Mar 12 01:13:36 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 8c000000
>>> Memory policy: Data cache writealloc
>>> <hang>
>>>
>>> vs.
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #631 SMP Wed Mar 12 01:15:37 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 3b800000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 524288
>>> free_area_init_node: node 0, pgdat c09d0240, node_mem_map ea7d8000
>>>     Normal zone: 1520 pages used for memmap
>>>     Normal zone: 0 pages reserved
>>>     Normal zone: 194560 pages, LIFO batch:31
>>>     HighMem zone: 2576 pages used for memmap
>>>     HighMem zone: 329728 pages, LIFO batch:31
>>> ...
>>>
>>> The only obvious difference is the address of that CMA reservation,
>>> CMA shouldn't make a difference here - but I suspect that other
>>> allocations which need to be in lowmem probably aren't.
>>>
>>
>> Could it be possible to enable memblock debug by adding "memblock=debug"
>> in cmdline?
> 
> Here's with Laura's patch:
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #633 SMP Wed Mar 12 12:56:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c1f7] flags 0x0 arm_memblock_init+0x28/0x1a8
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x108/0x1a8
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000008c000000-0x0000008fffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 8c000000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fda50
>   memory.cnt  = 0x1
>   memory[0x0]   [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x06
>   reserved.cnt  = 0x5
>   reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1] [0x00000010008240-0x0000001112c1f7], 0x1123fb8 bytes flags: 0x0
>   reserved[0x2] [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3] [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4] [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000008bffffd8-0x0000008bffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> 
> Here's without:
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #635 SMP Wed Mar 12 13:22:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c277] flags 0x0 arm_memblock_init+0x54/0x1d4
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x134/0x1d4
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000003b800000-0x0000003f7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 3b800000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fdad0
>   memory.cnt  = 0x1
>   memory[0x0]     [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x0
>   reserved.cnt  = 0x5
>   reserved[0x0]   [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1]   [0x00000010008240-0x0000001112c277], 0x1124038 bytes flags: 0x0
>   reserved[0x2]   [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3]   [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4]   [0x0000003b800000-0x0000003f7fffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000003b7fffd8-0x0000003b7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fe000-0x0000003b7fefff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fd000-0x0000003b7fdfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fc000-0x0000003b7fcfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> ...
> 
> So it looks like allocations which must come from lowmem aren't being
> limited to lowmem.
> 
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
> 
> In fact, if we look at sanity_check_meminfo() post that patch, it's
> clearly wrong:
> 
>          for_each_memblock(memory, reg) {
>                  phys_addr_t block_start = reg->base;
>                  phys_addr_t block_end = reg->base + reg->size;
>                  phys_addr_t size_limit = reg->size;
> 
>                  if (reg->base >= vmalloc_limit)
>                          highmem = 1;
>                  else
>                          size_limit = vmalloc_limit - reg->base;
> ...
>                  if (!highmem) {
>                          if (block_end > arm_lowmem_limit)
>                                  arm_lowmem_limit = block_end;

In v3, above was 
		arm_lowmem_limit = reg->base + size_limit;

so, it has worked somehow, even arm_lowmem_limit can point on non 
existed address. It was changed because of my comment - sorry.

I think, it should be smth like:
if (!highmem) {
	if (block_end > arm_lowmem_limit)
		if (reg->size > size_limit)
			arm_lowmem_limit = vmalloc_limit;
		else 
			arm_lowmem_limit = block_end;

I've created and attached the patch which allows me to boot on keystone.

> ...
>                  }

regards,
-grygorii

>From 3a210330f15c4cfc6728d83b28750c696d9eaefb Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <x0174654@uglx0174654.(none)>
Date: Wed, 12 Mar 2014 18:04:02 +0200
Subject: [PATCH] arm: get rid of meminfo: fix lowmem_limit calculation

Signed-off-by: Grygorii Strashko <x0174654@uglx0174654.(none)>
---
 arch/arm/mm/mmu.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c3ae96c..f8b5175 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1096,8 +1096,12 @@ void __init sanity_check_meminfo(void)
 		}
 
 		if (!highmem) {
-			if (block_end > arm_lowmem_limit)
-				arm_lowmem_limit = block_end;
+			if (block_end > arm_lowmem_limit) {
+				if (reg->size > size_limit)
+					arm_lowmem_limit = vmalloc_limit;
+				else
+					arm_lowmem_limit = block_end;
+			}
 
 
 			/*
@@ -1117,7 +1121,7 @@ void __init sanity_check_meminfo(void)
 				if (!IS_ALIGNED(block_start, SECTION_SIZE))
 					memblock_limit = block_start;
 				else if (!IS_ALIGNED(block_end, SECTION_SIZE))
-					memblock_limit = block_end;
+					memblock_limit = arm_lowmem_limit;
 			}
 
 		}
-- 
1.7.9.5

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 18:08:51 +0200	[thread overview]
Message-ID: <53208693.0@ti.com> (raw)
In-Reply-To: <20140312133806.GH21483@n2100.arm.linux.org.uk>

On 03/12/2014 03:38 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 12, 2014 at 03:09:53PM +0200, Grygorii Strashko wrote:
>> Hi Russell,
>>
>> On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
>>> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>>>> memblock is now fully integrated into the kernel and is the prefered
>>>> method for tracking memory. Rather than reinvent the wheel with
>>>> meminfo, migrate to using memblock directly instead of meminfo as
>>>> an intermediate.
>>>>
>>>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>>>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
>>>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>>>
>>> Laura,
>>>
>>> This patch causes a bunch of platforms to no longer boot - imx6solo with
>>> 1GB of RAM boots, imx6q with 2GB of RAM doesn't.  Versatile Express doesn't.
>>>
>>> The early printk messages don't reveal anything too interesting:
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #630 SMP Wed Mar 12 01:13:36 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 8c000000
>>> Memory policy: Data cache writealloc
>>> <hang>
>>>
>>> vs.
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #631 SMP Wed Mar 12 01:15:37 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 3b800000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 524288
>>> free_area_init_node: node 0, pgdat c09d0240, node_mem_map ea7d8000
>>>     Normal zone: 1520 pages used for memmap
>>>     Normal zone: 0 pages reserved
>>>     Normal zone: 194560 pages, LIFO batch:31
>>>     HighMem zone: 2576 pages used for memmap
>>>     HighMem zone: 329728 pages, LIFO batch:31
>>> ...
>>>
>>> The only obvious difference is the address of that CMA reservation,
>>> CMA shouldn't make a difference here - but I suspect that other
>>> allocations which need to be in lowmem probably aren't.
>>>
>>
>> Could it be possible to enable memblock debug by adding "memblock=debug"
>> in cmdline?
> 
> Here's with Laura's patch:
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #633 SMP Wed Mar 12 12:56:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c1f7] flags 0x0 arm_memblock_init+0x28/0x1a8
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x108/0x1a8
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000008c000000-0x0000008fffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 8c000000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fda50
>   memory.cnt  = 0x1
>   memory[0x0]   [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x06
>   reserved.cnt  = 0x5
>   reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1] [0x00000010008240-0x0000001112c1f7], 0x1123fb8 bytes flags: 0x0
>   reserved[0x2] [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3] [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4] [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000008bffffd8-0x0000008bffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> 
> Here's without:
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk at rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #635 SMP Wed Mar 12 13:22:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c277] flags 0x0 arm_memblock_init+0x54/0x1d4
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x134/0x1d4
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000003b800000-0x0000003f7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 3b800000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fdad0
>   memory.cnt  = 0x1
>   memory[0x0]     [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x0
>   reserved.cnt  = 0x5
>   reserved[0x0]   [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1]   [0x00000010008240-0x0000001112c277], 0x1124038 bytes flags: 0x0
>   reserved[0x2]   [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3]   [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4]   [0x0000003b800000-0x0000003f7fffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000003b7fffd8-0x0000003b7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fe000-0x0000003b7fefff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fd000-0x0000003b7fdfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fc000-0x0000003b7fcfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> ...
> 
> So it looks like allocations which must come from lowmem aren't being
> limited to lowmem.
> 
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
> 
> In fact, if we look at sanity_check_meminfo() post that patch, it's
> clearly wrong:
> 
>          for_each_memblock(memory, reg) {
>                  phys_addr_t block_start = reg->base;
>                  phys_addr_t block_end = reg->base + reg->size;
>                  phys_addr_t size_limit = reg->size;
> 
>                  if (reg->base >= vmalloc_limit)
>                          highmem = 1;
>                  else
>                          size_limit = vmalloc_limit - reg->base;
> ...
>                  if (!highmem) {
>                          if (block_end > arm_lowmem_limit)
>                                  arm_lowmem_limit = block_end;

In v3, above was 
		arm_lowmem_limit = reg->base + size_limit;

so, it has worked somehow, even arm_lowmem_limit can point on non 
existed address. It was changed because of my comment - sorry.

I think, it should be smth like:
if (!highmem) {
	if (block_end > arm_lowmem_limit)
		if (reg->size > size_limit)
			arm_lowmem_limit = vmalloc_limit;
		else 
			arm_lowmem_limit = block_end;

I've created and attached the patch which allows me to boot on keystone.

> ...
>                  }

regards,
-grygorii

>From 3a210330f15c4cfc6728d83b28750c696d9eaefb Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <x0174654@uglx0174654.(none)>
Date: Wed, 12 Mar 2014 18:04:02 +0200
Subject: [PATCH] arm: get rid of meminfo: fix lowmem_limit calculation

Signed-off-by: Grygorii Strashko <x0174654@uglx0174654.(none)>
---
 arch/arm/mm/mmu.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c3ae96c..f8b5175 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1096,8 +1096,12 @@ void __init sanity_check_meminfo(void)
 		}
 
 		if (!highmem) {
-			if (block_end > arm_lowmem_limit)
-				arm_lowmem_limit = block_end;
+			if (block_end > arm_lowmem_limit) {
+				if (reg->size > size_limit)
+					arm_lowmem_limit = vmalloc_limit;
+				else
+					arm_lowmem_limit = block_end;
+			}
 
 
 			/*
@@ -1117,7 +1121,7 @@ void __init sanity_check_meminfo(void)
 				if (!IS_ALIGNED(block_start, SECTION_SIZE))
 					memblock_limit = block_start;
 				else if (!IS_ALIGNED(block_end, SECTION_SIZE))
-					memblock_limit = block_end;
+					memblock_limit = arm_lowmem_limit;
 			}
 
 		}
-- 
1.7.9.5

WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Laura Abbott <lauraa@codeaurora.org>,
	David Brown <davidb@codeaurora.org>,
	Daniel Walker <dwalker@fifo99.com>,
	Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rob Herring <robherring2@gmail.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Courtney Cavin <courtney.cavin@sonymobile.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 18:08:51 +0200	[thread overview]
Message-ID: <53208693.0@ti.com> (raw)
In-Reply-To: <20140312133806.GH21483@n2100.arm.linux.org.uk>

On 03/12/2014 03:38 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 12, 2014 at 03:09:53PM +0200, Grygorii Strashko wrote:
>> Hi Russell,
>>
>> On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
>>> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>>>> memblock is now fully integrated into the kernel and is the prefered
>>>> method for tracking memory. Rather than reinvent the wheel with
>>>> meminfo, migrate to using memblock directly instead of meminfo as
>>>> an intermediate.
>>>>
>>>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>>>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
>>>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>>>
>>> Laura,
>>>
>>> This patch causes a bunch of platforms to no longer boot - imx6solo with
>>> 1GB of RAM boots, imx6q with 2GB of RAM doesn't.  Versatile Express doesn't.
>>>
>>> The early printk messages don't reveal anything too interesting:
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #630 SMP Wed Mar 12 01:13:36 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 8c000000
>>> Memory policy: Data cache writealloc
>>> <hang>
>>>
>>> vs.
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #631 SMP Wed Mar 12 01:15:37 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 3b800000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 524288
>>> free_area_init_node: node 0, pgdat c09d0240, node_mem_map ea7d8000
>>>     Normal zone: 1520 pages used for memmap
>>>     Normal zone: 0 pages reserved
>>>     Normal zone: 194560 pages, LIFO batch:31
>>>     HighMem zone: 2576 pages used for memmap
>>>     HighMem zone: 329728 pages, LIFO batch:31
>>> ...
>>>
>>> The only obvious difference is the address of that CMA reservation,
>>> CMA shouldn't make a difference here - but I suspect that other
>>> allocations which need to be in lowmem probably aren't.
>>>
>>
>> Could it be possible to enable memblock debug by adding "memblock=debug"
>> in cmdline?
> 
> Here's with Laura's patch:
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #633 SMP Wed Mar 12 12:56:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c1f7] flags 0x0 arm_memblock_init+0x28/0x1a8
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x108/0x1a8
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000008c000000-0x0000008fffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 8c000000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fda50
>   memory.cnt  = 0x1
>   memory[0x0]   [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x06
>   reserved.cnt  = 0x5
>   reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1] [0x00000010008240-0x0000001112c1f7], 0x1123fb8 bytes flags: 0x0
>   reserved[0x2] [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3] [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4] [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000008bffffd8-0x0000008bffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> 
> Here's without:
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #635 SMP Wed Mar 12 13:22:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c277] flags 0x0 arm_memblock_init+0x54/0x1d4
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x134/0x1d4
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000003b800000-0x0000003f7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 3b800000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fdad0
>   memory.cnt  = 0x1
>   memory[0x0]     [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x0
>   reserved.cnt  = 0x5
>   reserved[0x0]   [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1]   [0x00000010008240-0x0000001112c277], 0x1124038 bytes flags: 0x0
>   reserved[0x2]   [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3]   [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4]   [0x0000003b800000-0x0000003f7fffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000003b7fffd8-0x0000003b7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fe000-0x0000003b7fefff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fd000-0x0000003b7fdfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fc000-0x0000003b7fcfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> ...
> 
> So it looks like allocations which must come from lowmem aren't being
> limited to lowmem.
> 
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
> 
> In fact, if we look at sanity_check_meminfo() post that patch, it's
> clearly wrong:
> 
>          for_each_memblock(memory, reg) {
>                  phys_addr_t block_start = reg->base;
>                  phys_addr_t block_end = reg->base + reg->size;
>                  phys_addr_t size_limit = reg->size;
> 
>                  if (reg->base >= vmalloc_limit)
>                          highmem = 1;
>                  else
>                          size_limit = vmalloc_limit - reg->base;
> ...
>                  if (!highmem) {
>                          if (block_end > arm_lowmem_limit)
>                                  arm_lowmem_limit = block_end;

In v3, above was 
		arm_lowmem_limit = reg->base + size_limit;

so, it has worked somehow, even arm_lowmem_limit can point on non 
existed address. It was changed because of my comment - sorry.

I think, it should be smth like:
if (!highmem) {
	if (block_end > arm_lowmem_limit)
		if (reg->size > size_limit)
			arm_lowmem_limit = vmalloc_limit;
		else 
			arm_lowmem_limit = block_end;

I've created and attached the patch which allows me to boot on keystone.

> ...
>                  }

regards,
-grygorii

WARNING: multiple messages have this Message-ID (diff)
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Laura Abbott <lauraa@codeaurora.org>,
	David Brown <davidb@codeaurora.org>,
	Daniel Walker <dwalker@fifo99.com>,
	Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rob Herring <robherring2@gmail.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	<linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>,
	Courtney Cavin <courtney.cavin@sonymobile.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCHv4 2/2] arm: Get rid of meminfo
Date: Wed, 12 Mar 2014 18:08:51 +0200	[thread overview]
Message-ID: <53208693.0@ti.com> (raw)
In-Reply-To: <20140312133806.GH21483@n2100.arm.linux.org.uk>

On 03/12/2014 03:38 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 12, 2014 at 03:09:53PM +0200, Grygorii Strashko wrote:
>> Hi Russell,
>>
>> On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
>>> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>>>> memblock is now fully integrated into the kernel and is the prefered
>>>> method for tracking memory. Rather than reinvent the wheel with
>>>> meminfo, migrate to using memblock directly instead of meminfo as
>>>> an intermediate.
>>>>
>>>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>>>> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>>>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
>>>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>>>
>>> Laura,
>>>
>>> This patch causes a bunch of platforms to no longer boot - imx6solo with
>>> 1GB of RAM boots, imx6q with 2GB of RAM doesn't.  Versatile Express doesn't.
>>>
>>> The early printk messages don't reveal anything too interesting:
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #630 SMP Wed Mar 12 01:13:36 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 8c000000
>>> Memory policy: Data cache writealloc
>>> <hang>
>>>
>>> vs.
>>>
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #631 SMP Wed Mar 12 01:15:37 GMT 2014
>>> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: SolidRun Cubox-i Dual/Quad
>>> cma: CMA: reserved 64 MiB at 3b800000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 524288
>>> free_area_init_node: node 0, pgdat c09d0240, node_mem_map ea7d8000
>>>     Normal zone: 1520 pages used for memmap
>>>     Normal zone: 0 pages reserved
>>>     Normal zone: 194560 pages, LIFO batch:31
>>>     HighMem zone: 2576 pages used for memmap
>>>     HighMem zone: 329728 pages, LIFO batch:31
>>> ...
>>>
>>> The only obvious difference is the address of that CMA reservation,
>>> CMA shouldn't make a difference here - but I suspect that other
>>> allocations which need to be in lowmem probably aren't.
>>>
>>
>> Could it be possible to enable memblock debug by adding "memblock=debug"
>> in cmdline?
> 
> Here's with Laura's patch:
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #633 SMP Wed Mar 12 12:56:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c1f7] flags 0x0 arm_memblock_init+0x28/0x1a8
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x108/0x1a8
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000008c000000-0x0000008fffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 8c000000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fda50
>   memory.cnt  = 0x1
>   memory[0x0]   [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x06
>   reserved.cnt  = 0x5
>   reserved[0x0] [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1] [0x00000010008240-0x0000001112c1f7], 0x1123fb8 bytes flags: 0x0
>   reserved[0x2] [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3] [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4] [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000008bffffd8-0x0000008bffffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> 
> Here's without:
> 
> Booting Linux on physical CPU 0x0
> Linux version 3.14.0-rc6+ (rmk@rmk-PC.arm.linux.org.uk) (gcc version 4.6.4 (GCC) ) #635 SMP Wed Mar 12 13:22:15 GMT 2014
> CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: SolidRun Cubox-i Dual/Quad
> memblock_reserve: [0x00000010008240-0x0000001112c277] flags 0x0 arm_memblock_init+0x54/0x1d4
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_memblock_init+0x134/0x1d4
> memblock_reserve: [0x00000010004000-0x00000010007fff] flags 0x0 arm_mm_memblock_reserve+0x1c/0x24
> memblock_reserve: [0x00000018000000-0x0000001800b07f] flags 0x0 arm_dt_memblock_reserve+0x2c/0x70
> memblock_reserve: [0x00000018000000-0x0000001800afff] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x00000020000040-0x000000201caa57] flags 0x0 arm_dt_memblock_reserve+0x68/0x70
> memblock_reserve: [0x0000003b800000-0x0000003f7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> cma: CMA: reserved 64 MiB at 3b800000
> MEMBLOCK configuration:
>   memory size = 0x80000000 reserved size = 0x52fdad0
>   memory.cnt  = 0x1
>   memory[0x0]     [0x00000010000000-0x0000008fffffff], 0x80000000 bytes flags: 0x0
>   reserved.cnt  = 0x5
>   reserved[0x0]   [0x00000010004000-0x00000010007fff], 0x4000 bytes flags: 0x0
>   reserved[0x1]   [0x00000010008240-0x0000001112c277], 0x1124038 bytes flags: 0x0
>   reserved[0x2]   [0x00000018000000-0x0000001800b07f], 0xb080 bytes flags: 0x0
>   reserved[0x3]   [0x00000020000040-0x000000201caa57], 0x1caa18 bytes flags: 0x0
>   reserved[0x4]   [0x0000003b800000-0x0000003f7fffff], 0x4000000 bytes flags: 0x0
> Memory policy: Data cache writealloc
> memblock_reserve: [0x0000003b7fffd8-0x0000003b7fffff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fe000-0x0000003b7fefff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fd000-0x0000003b7fdfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> memblock_reserve: [0x0000003b7fc000-0x0000003b7fcfff] flags 0x0 memblock_alloc_base_nid+0x40/0x54
> ...
> 
> So it looks like allocations which must come from lowmem aren't being
> limited to lowmem.
> 
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
> 
> In fact, if we look at sanity_check_meminfo() post that patch, it's
> clearly wrong:
> 
>          for_each_memblock(memory, reg) {
>                  phys_addr_t block_start = reg->base;
>                  phys_addr_t block_end = reg->base + reg->size;
>                  phys_addr_t size_limit = reg->size;
> 
>                  if (reg->base >= vmalloc_limit)
>                          highmem = 1;
>                  else
>                          size_limit = vmalloc_limit - reg->base;
> ...
>                  if (!highmem) {
>                          if (block_end > arm_lowmem_limit)
>                                  arm_lowmem_limit = block_end;

In v3, above was 
		arm_lowmem_limit = reg->base + size_limit;

so, it has worked somehow, even arm_lowmem_limit can point on non 
existed address. It was changed because of my comment - sorry.

I think, it should be smth like:
if (!highmem) {
	if (block_end > arm_lowmem_limit)
		if (reg->size > size_limit)
			arm_lowmem_limit = vmalloc_limit;
		else 
			arm_lowmem_limit = block_end;

I've created and attached the patch which allows me to boot on keystone.

> ...
>                  }

regards,
-grygorii

>From 3a210330f15c4cfc6728d83b28750c696d9eaefb Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <x0174654@uglx0174654.(none)>
Date: Wed, 12 Mar 2014 18:04:02 +0200
Subject: [PATCH] arm: get rid of meminfo: fix lowmem_limit calculation

Signed-off-by: Grygorii Strashko <x0174654@uglx0174654.(none)>
---
 arch/arm/mm/mmu.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index c3ae96c..f8b5175 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1096,8 +1096,12 @@ void __init sanity_check_meminfo(void)
 		}
 
 		if (!highmem) {
-			if (block_end > arm_lowmem_limit)
-				arm_lowmem_limit = block_end;
+			if (block_end > arm_lowmem_limit) {
+				if (reg->size > size_limit)
+					arm_lowmem_limit = vmalloc_limit;
+				else
+					arm_lowmem_limit = block_end;
+			}
 
 
 			/*
@@ -1117,7 +1121,7 @@ void __init sanity_check_meminfo(void)
 				if (!IS_ALIGNED(block_start, SECTION_SIZE))
 					memblock_limit = block_start;
 				else if (!IS_ALIGNED(block_end, SECTION_SIZE))
-					memblock_limit = block_end;
+					memblock_limit = arm_lowmem_limit;
 			}
 
 		}
-- 
1.7.9.5

  parent reply	other threads:[~2014-03-12 16:08 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 22:15 [PATCHv4 0/2] Remove ARM meminfo Laura Abbott
2014-02-18 22:15 ` Laura Abbott
2014-02-18 22:15 ` Laura Abbott
2014-02-18 22:15 ` [PATCHv4 1/2] mm/memblock: add memblock_get_current_limit Laura Abbott
2014-02-18 22:15   ` Laura Abbott
2014-02-18 22:54   ` Nicolas Pitre
2014-02-18 22:54     ` Nicolas Pitre
2014-02-18 22:15 ` [PATCHv4 2/2] arm: Get rid of meminfo Laura Abbott
2014-02-18 22:15   ` Laura Abbott
2014-02-18 22:15   ` Laura Abbott
2014-02-18 23:07   ` Russell King - ARM Linux
2014-02-18 23:07     ` Russell King - ARM Linux
2014-02-18 23:07     ` Russell King - ARM Linux
2014-02-18 23:07     ` Russell King - ARM Linux
2014-02-18 23:49     ` Nicolas Pitre
2014-02-18 23:49       ` Nicolas Pitre
2014-02-18 23:49       ` Nicolas Pitre
2014-02-18 23:49       ` Nicolas Pitre
2014-02-18 23:47   ` Nicolas Pitre
2014-02-18 23:47     ` Nicolas Pitre
2014-02-18 23:47     ` Nicolas Pitre
2014-02-18 23:47     ` Nicolas Pitre
2014-03-12  8:54   ` Russell King - ARM Linux
2014-03-12  8:54     ` Russell King - ARM Linux
2014-03-12  8:54     ` Russell King - ARM Linux
2014-03-12  8:54     ` Russell King - ARM Linux
2014-03-12 13:09     ` Grygorii Strashko
2014-03-12 13:09       ` Grygorii Strashko
2014-03-12 13:09       ` Grygorii Strashko
2014-03-12 13:09       ` Grygorii Strashko
2014-03-12 13:38       ` Russell King - ARM Linux
2014-03-12 13:38         ` Russell King - ARM Linux
2014-03-12 13:38         ` Russell King - ARM Linux
2014-03-12 13:38         ` Russell King - ARM Linux
2014-03-12 14:05         ` Russell King - ARM Linux
2014-03-12 14:05           ` Russell King - ARM Linux
2014-03-12 14:05           ` Russell King - ARM Linux
2014-03-12 14:05           ` Russell King - ARM Linux
2014-03-12 16:08         ` Grygorii Strashko [this message]
2014-03-12 16:08           ` Grygorii Strashko
2014-03-12 16:08           ` Grygorii Strashko
2014-03-12 16:08           ` Grygorii Strashko
2014-03-19 18:23           ` Laura Abbott
2014-03-19 18:23             ` Laura Abbott
2014-03-19 18:23             ` Laura Abbott
2014-03-19 18:23             ` Laura Abbott
2014-03-12 14:44   ` Russell King - ARM Linux
2014-03-12 14:44     ` Russell King - ARM Linux
2014-03-12 14:44     ` Russell King - ARM Linux
2014-03-12 14:44     ` Russell King - ARM Linux

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=53208693.0@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=andrew@lunn.ch \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ben-linux@fluff.org \
    --cc=catalin.marinas@arm.com \
    --cc=davidb@codeaurora.org \
    --cc=dwalker@fifo99.com \
    --cc=eric.y.miao@gmail.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=jason@lakedaemon.net \
    --cc=kgene.kim@samsung.com \
    --cc=lauraa@codeaurora.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nicolas.pitre@linaro.org \
    --cc=robherring2@gmail.com \
    --cc=santosh.shilimkar@ti \
    --cc=sebastian.hesselbarth@gmail.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.