From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) by kanga.kvack.org (Postfix) with ESMTP id 8973C6B0032 for ; Sat, 17 Jan 2015 03:39:12 -0500 (EST) Received: by mail-we0-f174.google.com with SMTP id k48so23794676wev.5 for ; Sat, 17 Jan 2015 00:39:11 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com. [74.125.82.41]) by mx.google.com with ESMTPS id la7si12915912wjc.139.2015.01.17.00.39.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Jan 2015 00:39:11 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id a1so2085296wgh.0 for ; Sat, 17 Jan 2015 00:39:11 -0800 (PST) Message-ID: <54BA1FAC.6090902@linaro.org> Date: Sat, 17 Jan 2015 08:39:08 +0000 From: Srinivas Kandagatla MIME-Version: 1.0 Subject: Re: Issue on reserving memory with no-map flag in DT References: <54B8F63C.1060300@linaro.org> <54B9ABAA.9060908@codeaurora.org> In-Reply-To: <54B9ABAA.9060908@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , "linux-arm-kernel@lists.infradead.org" , linux@arm.linux.org.uk, ssantosh@kernel.org, Andrew Morton , Mel Gorman Cc: Kevin Hilman , Stephen Boyd , Arnd Bergmann , Kumar Gala , linux-mm@kvack.org On 17/01/15 00:24, Laura Abbott wrote: > (Adding linux-mm and relevant people because this looks like an issue > there) > > On 1/16/2015 3:30 AM, Srinivas Kandagatla wrote: >> Hi All, >> >> I am hitting boot failures when I did try to reserve memory with >> no-map flag using DT. Basically kernel just hangs with no indication >> of whats going on. Added some debug to find out the location, it was >> some where while dma mapping at kmap_atomic() in __dma_clear_buffer(). >> reserving. >> >> The issue is very much identical to >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294773.html >> but the memory reserve in my case is at start of the memory. I tried >> the same fixes on this thread but it did not help. >> >> Platform: IFC6410 with APQ8064 which is a v7 platform with 2GB of >> memory starting at 0x80000000 and kernel is always loaded at 0x80200000 >> And am using multi_v7_defconfig. >> >> Meminfo without memory reserve: >> 80000000-88dfffff : System RAM >> 80208000-80e5d307 : Kernel code >> 80f64000-810be397 : Kernel data >> 8a000000-8d9fffff : System RAM >> 8ec00000-8effffff : System RAM >> 8f700000-8fdfffff : System RAM >> 90000000-af7fffff : System RAM >> >> DT entry: >> reserved-memory { >> #address-cells = <1>; >> #size-cells = <1>; >> ranges; >> smem@80000000 { >> reg = <0x80000000 0x200000>; >> no-map; >> }; >> }; >> >> If I remove the no-map flag, then I can boot the board. But I dona??t >> want kernel to map this memory at all, as this a IPC memory. >> >> I just wanted to understand whats going on here, Am guessing that >> kernel would never touch that 2MB memory. >> >> Does arm-kernel has limitation on unmapping/memblock_remove() such >> memory locations? >> Or >> Is this a known issue? >> >> Any pointers to debug this issue? >> >> Before the kernel hangs it reports 2 errors like: >> >> BUG: Bad page state in process swapper pfn:fffa8 >> page:ef7fb500 count:0 mapcount:0 mapping: (null) index:0x0 >> flags: 0x96640253(locked|error|dirty|active|arch_1|reclaim|mlocked) >> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set >> bad because of flags: >> flags: 0x200041(locked|active|mlocked) >> Modules linked in: >> CPU: 0 PID: 0 Comm: swapper Not tainted >> 3.19.0-rc3-00007-g412f9ba-dirty #816 >> Hardware name: Qualcomm (Flattened Device Tree) >> [] (unwind_backtrace) from [] (show_stack+0x20/0x24) >> [] (show_stack) from [] (dump_stack+0x80/0x9c) >> [] (dump_stack) from [] (bad_page+0xc8/0x128) >> [] (bad_page) from [] >> (free_pages_prepare+0x168/0x1e0) >> [] (free_pages_prepare) from [] >> (free_hot_cold_page+0x3c/0x174) >> [] (free_hot_cold_page) from [] >> (__free_pages+0x54/0x58) >> [] (__free_pages) from [] >> (free_highmem_page+0x38/0x88) >> [] (free_highmem_page) from [] (mem_init+0x240/0x430) >> [] (mem_init) from [] (start_kernel+0x1e4/0x3c8) >> [] (start_kernel) from [<80208074>] (0x80208074) >> Disabling lock debugging due to kernel taint >> >> >> Full kernel log with memblock debug at http://paste.ubuntu.com/9761000/ >> > > I don't have an IFC handy but I was able to reproduce the same issue on > another board. > I think this is an underlying issue in mm code. > > Removing the first 2MB changes the start address of the zone. This means > the start > address is no longer pageblock aligned (4MB on this system). With a little > digging, it looks like the issue is we're running off the end of the end > of the > mem_map array because the memmap array is too small. This is similar to > an issue fixed by 7c45512 mm: fix pageblock bitmap allocation and the > following > fixes it for me: Thanks Laura, This patch indeed fixes issue for me too. Tested-by: Srinivas Kandagatla > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 7633c50..32d9436 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5012,7 +5012,7 @@ static void __init_refok alloc_node_mem_map(struct > pglist_data *pgdat) > #ifdef CONFIG_FLAT_NODE_MEM_MAP > /* ia64 gets its own node_mem_map, before this, without bootmem */ > if (!pgdat->node_mem_map) { > - unsigned long size, start, end; > + unsigned long size, start, end, offset; > struct page *map; > > /* > @@ -5020,10 +5020,11 @@ static void __init_refok > alloc_node_mem_map(struct pglist_data *pgdat) > * aligned but the node_mem_map endpoints must be in order > * for the buddy allocator to function correctly. > */ > + offset = pgdat->node_start_pfn & (pageblock_nr_pages - 1); > start = pgdat->node_start_pfn & ~(MAX_ORDER_NR_PAGES - 1); > end = pgdat_end_pfn(pgdat); > end = ALIGN(end, MAX_ORDER_NR_PAGES); > - size = (end - start) * sizeof(struct page); > + size = ((end - start) + offset) * sizeof(struct page); > map = alloc_remap(pgdat->node_id, size); > if (!map) > map = memblock_virt_alloc_node_nopanic(size, > > If there is agreement on this approach, I can turn this into a proper > patch. > > Thanks, > Laura > -- 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: email@kvack.org