From patchwork Tue Mar 17 12:05:58 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 6031501 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 194D99F399 for ; Tue, 17 Mar 2015 12:09:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9AD9620458 for ; Tue, 17 Mar 2015 12:09:08 +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 1929A2045B for ; Tue, 17 Mar 2015 12:09:03 +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 1YXqGE-0001Gw-8G; Tue, 17 Mar 2015 12:06:14 +0000 Received: from service87.mimecast.com ([91.220.42.44]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YXqGA-0001DI-Uv for linux-arm-kernel@lists.infradead.org; Tue, 17 Mar 2015 12:06:11 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Tue, 17 Mar 2015 12:05:44 +0000 Received: from [10.1.207.150] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2015 12:05:42 +0000 Message-ID: <550818A6.9020205@arm.com> Date: Tue, 17 Mar 2015 12:05:58 +0000 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Russell King - ARM Linux Subject: Re: Versatile Express randomly fails to boot - Versatile Express to be removed from nightly testing References: <20150315213330.GB8656@n2100.arm.linux.org.uk> <20150316000438.GD8656@n2100.arm.linux.org.uk> <20150316004239.GE8656@n2100.arm.linux.org.uk> <20150316093553.GF8656@n2100.arm.linux.org.uk> <20150316130419.GI8656@n2100.arm.linux.org.uk> <55071742.6000405@arm.com> <20150316181634.GK8656@n2100.arm.linux.org.uk> <55072BF5.7030901@arm.com> <20150316195255.GM8656@n2100.arm.linux.org.uk> In-Reply-To: <20150316195255.GM8656@n2100.arm.linux.org.uk> X-OriginalArrivalTime: 17 Mar 2015 12:05:42.0225 (UTC) FILETIME=[B0E50410:01D060AA] X-MC-Unique: 115031712054403701 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150317_050611_288787_73A2F122 X-CRM114-Status: GOOD ( 12.28 ) X-Spam-Score: -2.3 (--) Cc: "daniel.thompson@linaro.org" , Will Deacon , "linux-arm-kernel@lists.infradead.org" , Sudeep Holla 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-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 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 16/03/15 19:52, Russell King - ARM Linux wrote: > On Mon, Mar 16, 2015 at 07:16:05PM +0000, Sudeep Holla wrote: >> On 16/03/15 18:16, Russell King - ARM Linux wrote: [...] > If I had to guess, I'd say the reason it's stopped there (exactly on a > cache line boundary) is because both CPUs are waiting for an instruction > fetch to complete into its L1 I-cache, and for some reason, the L2 > cache is not satisfying the request from either CPU. The question of > course is... why not. > As I had mentioned yesterday, I did compare the L2C settings between v3.18 and later kernel and found them to be *exactly same*. Since you suspected issues around instruction fetching, I tried playing around the tag and data ram latencies. After some experiments, I found that changing just the tag ram read latency to 2 cycles, the issue we are seeing goes away at-least on my setup. It will be good to see the behaviour on your setup with the patch below. The default value which bootmon is programming happens to be worst case scenario(8 cycles for all). Will recalls that it was changed to minimum value after graphics guys complained about performance. We need to check with h/w guys to get the correct optimal values for these latencies. Regards, Sudeep --->8 diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts index 23662b5a5e9d..030c90c1105d 100644 --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts @@ -172,7 +172,7 @@ interrupts = <0 43 4>; cache-level = <2>; arm,data-latency = <1 1 1>; - arm,tag-latency = <1 1 1>; + arm,tag-latency = <1 2 1>; }; pmu {