Re: 3.18.1->3.19-rc2: In-band Error seen by MPU

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]

Hi,

On Mon, Jan 05, 2015 at 04:12:51PM -0800, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [150105 15:19]:
> > 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 <tony@atomide.com>
> > > > > > 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 <balbi@ti.com>
> > > > 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?
> > 
> > With the commit before the "arm: omap: intc: switch over
> > to linear irq domain" it seems to be more reasonable:
> > 
> >  28:          0      INTC  12  DMA
> 
> Hmm stange. Felipe, chances are this wrong interrupt issue also
> exists on am33xx but it's not showing up as the legacy DMA is not
> being used.

not really, AM335x doesn't use sDMA, only EDMA.

> Note that currently legacy DMA and drivers/dma/omap-dma.c are
> using separate interrupts as they are mappable. It seems this
> issue is affecting legacy DMA.

makes sense now after readin plat-omap/dma.c (that thing needs to go :-)

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]