From patchwork Tue Jun 24 22:29:09 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laura Abbott X-Patchwork-Id: 4414481 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5F2339F402 for ; Tue, 24 Jun 2014 22:29:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C54DC20320 for ; Tue, 24 Jun 2014 22:29:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B855520304 for ; Tue, 24 Jun 2014 22:29:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbaFXW3N (ORCPT ); Tue, 24 Jun 2014 18:29:13 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:34281 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751826AbaFXW3M (ORCPT ); Tue, 24 Jun 2014 18:29:12 -0400 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 409C2140530; Tue, 24 Jun 2014 22:29:12 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id 3075F14050B; Tue, 24 Jun 2014 22:29:12 +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=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from [10.42.111.116] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1 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 7007B14050B; Tue, 24 Jun 2014 22:29:11 +0000 (UTC) Message-ID: <53A9FBB5.60709@codeaurora.org> Date: Tue, 24 Jun 2014 15:29:09 -0700 From: Laura Abbott User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kevin Hilman , Tushar Behera CC: "linux-samsung-soc@vger.kernel.org" , Russell King , kernel-build-reports@lists.linaro.org, "linaro-kernel@lists.linaro.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618) References: <539fdd37.e7bc420a.76b9.ffffb583@mx.google.com> <53A106F1.10201@gmail.com> <53A2AE11.2050208@gmail.com> <53A2BE94.2010308@gmail.com> <53A7A579.4010702@gmail.com> <53A9B99F.4040806@codeaurora.org> In-Reply-To: <53A9B99F.4040806@codeaurora.org> X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 6/24/2014 10:47 AM, Laura Abbott wrote: > On 6/23/2014 11:32 AM, Kevin Hilman wrote: >> On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera wrote: >>> Adding linux-samsung-soc and linux-arm-kernel ML for wider audience. >>> >>> On 06/19/2014 04:12 PM, Tushar Behera wrote: >>>> On 06/19/2014 03:02 PM, Tushar Behera wrote: >>>>> On 06/18/2014 09:22 AM, Kevin Hilman wrote: >>>>>> On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera wrote: >>>>>>> On 06/17/2014 10:23 PM, Kevin Hilman wrote: >>>>>>>> Sachin, >>>>>>>> >>>>>>>> On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot wrote: >>>>>>>>> >>>>>>>>> Tree/Branch: mainline >>>>>>>>> Git describe: v3.16-rc1-2-gebe0618 >>>>>>>>> Failed boot tests (console logs at the end) >>>>>>>>> =========================================== >>>>>>>>> exynos5420-arndale-octa: FAIL: arm-exynos_defconfig >>>>>>>>> ste-snowball: FAIL: arm-u8500_defconfig >>>>>>>> >>>>>>>> FYI... these failures are getting more consistent on my octa board, >>>>>>>> but still not failing every time. >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>> >>>>>>> Hi Kevin, >>>>>>> >>>>>>> Same here. >>>>>>> >>>>>>> Observation: If you soft-reset the board (through the jumpers) after >>>>>>> getting this problem, the problem keeps repeating. But if you hard-reset >>>>>>> the board (by removing the power cord), the problem doesn't occur during >>>>>>> next iteration. >>>>>> >>>>>> I don't ever use the soft-reset, I only toggle the wall power. I >>>>>> don't ever actually remove the power cord though, I'm using a >>>>>> USB-controlled relay to toggle the wall power. >>>>>> >>>>>> Kevin >>>>>> >>>>> >>>>> Laura, >>>>> >>>>> We are getting following kernel panic [1] (not always, but quite >>>>> regularly) while booting Arndale-Octa (based on Samsung's Exynos5420) >>>>> board with upstream kernel. I haven't observed this issue with other >>>>> boards yet. >>>>> >>>>> This issue is observed when I am booting with uImage + dtb (within >>>>> roughly ~10 iterations). >>>>> >>>> >>>> Some more information: >>>> >>>> The boot logs are provided in pastebin, okay[2] and failed[3]. >>>> >>>> In case of boot failures, I am getting a higher value for vm_total_pages >>>> (684424 in [3]). In case of successful boot on my board, it is always >>>> 521232 [2] on my board. >> >> I can confirm that reverting the "Get rid of meminfo" patch gets the >> Octa board booting reliably again for me also. >> >> In case it helps, some boot logs for failures from the last copule >> linux-next build/boot cycles can be seen here: >> http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log >> http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log >> > > Sorry, I missed this yesterday. I'm going to take a look. > Were all of http://pastebin.com/1iLaizuL http://pastebin.com/5tdDt4GL http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log collected on the same type of board with the same amount of DRAM? I'm seeing a different amount of total pages across all those logs. All the logs have the same lowmem limit so it seems like the upper bound was being calculated incorrectly for passing to free_area_init_node. Nothing is immediately jumping out at me so can you boot up with a small debug patch? It would be helpful to do this across a few bootups to see if the values are actually consistent. I'll keep looking in the meantime. Thanks, Laura diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 659c75d..88eac1f 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -187,6 +187,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max_low, unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES]; struct memblock_region *reg; + pr_err("XXXXXXX min %lx max_low %lx max_high %lx\n", min, max_low, max_high); + __memblock_dump_all(); /* * initialise the zones. */