From patchwork Sat Jan 17 00:24:10 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Laura Abbott X-Patchwork-Id: 5651061 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 095EBC058D for ; Sat, 17 Jan 2015 00:31:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0ABE1203F1 for ; Sat, 17 Jan 2015 00:31:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 00F89203EB for ; Sat, 17 Jan 2015 00:31:00 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YCHFO-0004LH-Jg; Sat, 17 Jan 2015 00:28:14 +0000 Received: from smtp.codeaurora.org ([198.145.11.231]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1YCHBp-0000qo-J3 for linux-arm-kernel@lists.infradead.org; Sat, 17 Jan 2015 00:24:34 +0000 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 7BB1913FF25; Sat, 17 Jan 2015 00:24:11 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id 6D95E13FF52; Sat, 17 Jan 2015 00:24:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from [10.42.111.116] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: lauraa@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 8CE4413FF25; Sat, 17 Jan 2015 00:24:10 +0000 (UTC) Message-ID: <54B9ABAA.9060908@codeaurora.org> Date: Fri, 16 Jan 2015 16:24:10 -0800 From: Laura Abbott User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Srinivas Kandagatla , "linux-arm-kernel@lists.infradead.org" , linux@arm.linux.org.uk, ssantosh@kernel.org, Andrew Morton , Mel Gorman Subject: Re: Issue on reserving memory with no-map flag in DT References: <54B8F63C.1060300@linaro.org> In-Reply-To: <54B8F63C.1060300@linaro.org> X-Virus-Scanned: ClamAV using ClamSMTP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150116_162433_768901_7E3FCAA1 X-CRM114-Status: GOOD ( 29.22 ) X-Spam-Score: -0.0 (/) Cc: linux-mm@kvack.org, Kevin Hilman , Stephen Boyd , Arnd Bergmann , Kumar Gala X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP (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 don’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: If there is agreement on this approach, I can turn this into a proper patch. Thanks, Laura 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,