From patchwork Tue Jan 6 02:01:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Felipe Balbi X-Patchwork-Id: 5571101 Return-Path: X-Original-To: patchwork-linux-omap@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 5015E9F357 for ; Tue, 6 Jan 2015 02:02:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 785EC20340 for ; Tue, 6 Jan 2015 02:02:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EE1D20306 for ; Tue, 6 Jan 2015 02:02:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbbAFCCX (ORCPT ); Mon, 5 Jan 2015 21:02:23 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:52847 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753388AbbAFCCX (ORCPT ); Mon, 5 Jan 2015 21:02:23 -0500 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id t0621t2a028810; Mon, 5 Jan 2015 20:01:55 -0600 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t0621tHE027326; Mon, 5 Jan 2015 20:01:55 -0600 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.174.1; Mon, 5 Jan 2015 20:01:54 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id t0621siQ027887; Mon, 5 Jan 2015 20:01:54 -0600 Date: Mon, 5 Jan 2015 20:01:22 -0600 From: Felipe Balbi To: Aaro Koskinen CC: Felipe Balbi , Tony Lindgren , Peter =?iso-8859-1?Q?K=FCmmel?= , , Pavel Machek , Russell King , Santosh Shilimkar Subject: Re: 3.18.1->3.19-rc2: In-band Error seen by MPU Message-ID: <20150106020122.GA24980@saruman> Reply-To: References: <20150101182053.GG582@fuloong-minipc.musicnaut.iki.fi> <20150102161911.GA3298@atomide.com> <54A6E408.1090908@gmx.net> <20150102201908.GK582@fuloong-minipc.musicnaut.iki.fi> <20150102204018.GF3298@atomide.com> <20150102223451.GL582@fuloong-minipc.musicnaut.iki.fi> <20150103000220.GE3279@atomide.com> <20150103121622.GN582@fuloong-minipc.musicnaut.iki.fi> <20150105154313.GA19336@saruman> <20150105231620.GC30544@fuloong-minipc.musicnaut.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150105231620.GC30544@fuloong-minipc.musicnaut.iki.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, 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 Hi, On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote: > Hi, > > On Mon, Jan 05, 2015 at 09:43:13AM -0600, Felipe Balbi wrote: > > On Sat, Jan 03, 2015 at 02:16:22PM +0200, Aaro Koskinen wrote: > > > > > > > > >>>When updating (custom DM3730 board) from 3.18.1 ro 3.19-rc2 > > > > > > > > >>>I see a "In-band ERROR" warning which wasn't present in 3.18.1. > > > > > > > > >>>Could it be that I missed some DT updates? > > > > > > > > >> > > > > > > > > >>>[ 0.366882] In-band Error seen by MPU at address 0 > > > > > > > > >>>[ 0.366912] ------------[ cut here ]------------ > > > > > > > > >>>[ 0.366943] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0x100/0x134() > > > > > > > > >> > > > > > > > > >>This appears also on N900/N950/N9... > > > > > > > > > > > > > > > > > >Do you have CONFIG_PREEMPT enabled? It seems there's some > > > > > > > > >regression related to CONFIG_PREEMPT that started happening > > > > > > > > >with the merge window? > > > > > > > > > > > > > > > > Indeed, when I disable CONFIG_PREEMPT the warning is gone. > > > > > > > > > > > > > > Yeah, disabling CONFIG_PREEMPT helps here too. Is there some e-mail > > > > > > > thread / patch set for this already; or should we try to bisect this? > > > > > > > > > > > > AFAIK I'm not aware of other threads, I noticied it with the > > > > > > "OMAP 4430 SDP: rather sick with recent kernels" thread, but > > > > > > never got anywhere with it. > > > > > > > > > > > > Yeah it seems it's somewhere between v3.18 and v3.19-rc1, but > > > > > > that too should be verified. Sounds like running git bisect on > > > > > > this one is needed. > > > > > > > > > > I tried to bisect this on N950, and it resulted in: > > > > > > > > > > aa25729cfd9709156661bea0f9293deb7729f57a is the first bad commit > > > > > commit aa25729cfd9709156661bea0f9293deb7729f57a > > > > > Author: Tony Lindgren > > > > > Date: Wed Nov 5 09:21:23 2014 -0800 > > > > > > > > > > ARM: OMAP3: Fix errors for omap_l3_smx when booted with device tree > > > > > > > > > > But when I tried to revert this from 3.19-rc2, my board won't boot at > > > > > all... > > > > > > > > Hmm OK that commit just fixed the omap_l3_smx so we now see > > > > warnings about the unclocked register access. > > > > > > > > It seems that probably the CONFIG_PREEMPT issue has been lurking > > > > around for longer but we have not seen any errors because > > > > omap_l3_smx just recently started exposing them. > > > > > > > > Does v3.18 + commit aa25729cfd9 manually applied also produce > > > > the CONFIG_PREEMPT errors? > > > > > > Yes it does, so I made another bisection between 3.17 and 3.18 > > > using the above patch to trigger the issue, and I got: > > > > > > 55601c9f24670ba926ebdd4d712ac3b177232330 is the first bad commit > > > commit 55601c9f24670ba926ebdd4d712ac3b177232330 > > > Author: Felipe Balbi > > > Date: Mon Sep 8 17:54:58 2014 -0700 > > > > > > arm: omap: intc: switch over to linear irq domain > > > > Just booted AM335x with CONFIG_PREEMPT and haven't seen any problem. > > Perhaps this is something related to another OMAP3-only driver ? Perhaps > > HSI/SSI ? > > I did some debugging and it seems the "In-band Error" > occurs when omap_system_dma_probe() is being run, specifically when > the interrupt is enabled. I believe the "DMA" interrupt it's trying > set up is completely wrong: > > 28: 0 GPIO 2 DMA > > GPIO 2?! Where is that coming from? heh, it's probably the linux number used ended up mapping to another irq domain. Can you add this debugging patch and report dmesg ? Note that I need one log post commit and another log pre commit. If any of the IRQ numbers change, if means that irq_domain_add_linear() ended up changing IRQ start and we would need some trick to grab the correct IRQ number again. cheers diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 24770e5..b3f6dcd 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -1380,6 +1380,8 @@ static int omap_system_dma_probe(struct platform_device *pdev) if (dma_omap2plus() && !(d->dev_caps & DMA_ENGINE_HANDLE_IRQ)) { strcpy(irq_name, "0"); dma_irq = platform_get_irq_byname(pdev, irq_name); + dev_info(&pdev->dev, "legacy DMA IRQ %d\n", dma_irq); + if (dma_irq < 0) { dev_err(&pdev->dev, "failed: request IRQ %d", dma_irq); ret = dma_irq; diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index c0016a6..98fe2d2 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1155,6 +1155,8 @@ static int omap_dma_probe(struct platform_device *pdev) } irq = platform_get_irq(pdev, 1); + + dev_info(&pdev->dev, "dmaengine IRQ %d\n", irq); if (irq <= 0) { dev_info(&pdev->dev, "failed to get L1 IRQ: %d\n", irq); od->legacy = true;