Hi, On Mon, Jan 05, 2015 at 04:12:51PM -0800, Tony Lindgren wrote: > * Aaro Koskinen <aaro.koskinen@xxxxxx> [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@xxxxxxxxxxx> > > > > > > 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@xxxxxx> > > > > 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:
signature.asc
Description: Digital signature
