Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Am 06.01.2015 um 13:47 schrieb Aaro Koskinen: Hi, On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote: On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote: Am 05.01.2015 um 16:43 schrieb Felipe Balbi: 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 see a ssi error directly before the IN-Band error: [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.346893] In-band Error seen by MPU at address 0 [0.346923] [ cut here ] mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi. This log occurs also on 3630, because ssi hwmod stuff is missing from omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need to be added since we should get nokia-modem working also on N950/N9... Peter: if you boot with "initcall_debug", you should see the error is during the DMA setup. DMA is not a module here thus loaded before the initcall. I've tried with CONFIG_DMADEVICES_DEBUG but then kernel didn't start at all. Absolutely no messages. A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Am 06.01.2015 um 12:52 schrieb Sebastian Reichel:
Hi,
On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
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 see a ssi error directly before the IN-Band error:
[0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
[0.346893] In-band Error seen by MPU at address 0
[0.346923] [ cut here ]
mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
should be disabled for those SoCs:
&ssi {
status = "disabled";
};
Indeed, I include omap36xx.dtsi.
Disabling ssi removes ssi the error.
But the In-Band error is still there, so not related to ssi.
I also see these errors:
omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp2: cannot be enabled for reset (3)
and
irq: no irq domain found for /ocp/pinmux@48002030 !
Could these errors also be fixed by the dts.
Peter
From what I can see the following in-tree .dts files should be
fixed, too:
* am3517_mt_ventoux.dts
Currently includes "omap34xx.dtsi" instead of "am3517.dtsi".
Apart from that the following boards seem to use omap36xx.dtsi
include, but are actually DM37xx, so they should disable the
ssi block:
* omap3-igep.dtsi
* omap3-lilly-a83x.dtsi
* omap3-overo-storm.dtsi
I will prepare a patch for that later.
-- Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Tue, Jan 06, 2015 at 12:52:50PM +0100, Sebastian Reichel wrote: > On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote: > > Am 05.01.2015 um 16:43 schrieb Felipe Balbi: > > >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 see a ssi error directly before the IN-Band error: > > > > [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' > > [0.346893] In-band Error seen by MPU at address 0 > > [0.346923] [ cut here ] > > mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi. This log occurs also on 3630, because ssi hwmod stuff is missing from omap36xx_hwmod_ocp_ifs... Anyway, it's not related to this error, but need to be added since we should get nokia-modem working also on N950/N9... Peter: if you boot with "initcall_debug", you should see the error is during the DMA setup. A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi,
On Mon, Jan 05, 2015 at 08:01:22PM -0600, Felipe Balbi wrote:
> On Tue, Jan 06, 2015 at 01:16:21AM +0200, Aaro Koskinen wrote:
> > 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 ?
Post-commit:
[0.208251] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216125] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 22
22: 5 INTC 13 omap-dma-engine
28: 0 GPIO 2 DMA
Pre-commit:
[0.208557] omap_dma_system omap_dma_system.0: legacy DMA IRQ 28
[0.216461] omap-dma-engine 48056000.dma-controller: dmaengine IRQ 29
28: 0 INTC 12 DMA
29: 5 INTC 13 omap-dma-engine
> 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.
So looks like static OMAP_INTC_START cannot be used anymore, but hwmod
data is full of these?
mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c: { .name = "0", .irq = 12 +
OMAP_INTC_START, }, /* INT_24XX_SDMA_IRQ0 */
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi,
On Tue, Jan 06, 2015 at 12:25:12PM +0100, Peter Kümmel wrote:
> Am 05.01.2015 um 16:43 schrieb Felipe Balbi:
> >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 see a ssi error directly before the IN-Band error:
>
> [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi'
> [0.346893] In-band Error seen by MPU at address 0
> [0.346923] [ cut here ]
mh I guess your board's dts included omap36xx.dtsi or omap34xx.dtsi.
Since ssi controller is not available on DM3xxx/AM3xxx (AFAIK) it
should be disabled for those SoCs:
&ssi {
status = "disabled";
};
From what I can see the following in-tree .dts files should be
fixed, too:
* am3517_mt_ventoux.dts
Currently includes "omap34xx.dtsi" instead of "am3517.dtsi".
Apart from that the following boards seem to use omap36xx.dtsi
include, but are actually DM37xx, so they should disable the
ssi block:
* omap3-igep.dtsi
* omap3-lilly-a83x.dtsi
* omap3-overo-storm.dtsi
I will prepare a patch for that later.
-- Sebastian
signature.asc
Description: Digital signature
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Am 05.01.2015 um 16:43 schrieb Felipe Balbi: 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 ? cheers I see a ssi error directly before the IN-Band error: [0.339935] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [0.346893] In-band Error seen by MPU at address 0 [0.346923] [ cut here ] Peter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Mon, Jan 05, 2015 at 04:12:51PM -0800, Tony Lindgren wrote: > * Aaro Koskinen [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 > > > > > > 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? > > > > 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 signature.asc Description: Digital signature
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
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 ?
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;
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 s
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
* Aaro Koskinen [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 > > > > > 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? > > 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. 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. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
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? 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 A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, 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 ? cheers -- balbi signature.asc Description: Digital signature
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Fri, Jan 02, 2015 at 04:02:21PM -0800, Tony Lindgren wrote: > * Aaro Koskinen [150102 14:37]: > > On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote: > > > * Aaro Koskinen [150102 12:21]: > > > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: > > > > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren: > > > > > >* Aaro Koskinen [150101 10:23]: > > > > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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 A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Am 03.01.2015 um 01:02 schrieb Tony Lindgren: * Aaro Koskinen [150102 14:37]: Hi, On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote: * Aaro Koskinen [150102 12:21]: On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: Am 02.01.2015 um 17:19 schrieb Tony Lindgren: * Aaro Koskinen [150101 10:23]: On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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, same error. I applied it on top of v3.18.1. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
* Aaro Koskinen [150102 14:37]: > Hi, > > On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote: > > * Aaro Koskinen [150102 12:21]: > > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: > > > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren: > > > > >* Aaro Koskinen [150101 10:23]: > > > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Fri, Jan 02, 2015 at 12:40:19PM -0800, Tony Lindgren wrote: > * Aaro Koskinen [150102 12:21]: > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: > > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren: > > > >* Aaro Koskinen [150101 10:23]: > > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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... A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
* Aaro Koskinen [150102 12:21]: > Hi, > > On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: > > Am 02.01.2015 um 17:19 schrieb Tony Lindgren: > > >* Aaro Koskinen [150101 10:23]: > > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Fri, Jan 02, 2015 at 07:31:36PM +0100, Peter Kümmel wrote: > Am 02.01.2015 um 17:19 schrieb Tony Lindgren: > >* Aaro Koskinen [150101 10:23]: > >>On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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? Thanks, A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Am 02.01.2015 um 17:19 schrieb Tony Lindgren: * Aaro Koskinen [150101 10:23]: Hi, On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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. Thanks, Peter Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
* Aaro Koskinen [150101 10:23]: > Hi, > > On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.18.1->3.19-rc2: In-band Error seen by MPU
Hi, On Thu, Jan 01, 2015 at 07:12:51PM +0100, Peter Kümmel 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... A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.18.1->3.19-rc2: In-band Error seen by MPU
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? And should I care of "irq: no irq domain found for /ocp/pinmux@48002030"? Many thanks! [0.00] Preemptible hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Clocking rate (Crystal/Core/MPU): 26.0/166/600 MHz [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 655360ns [0.30] OMAP clocksource: 32k_counter at 32768 Hz [0.000183] Console: colour dummy device 80x30 [0.000244] Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032) [0.118988] pid_max: default: 32768 minimum: 301 [0.119140] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.119171] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.119934] CPU: Testing write buffer coherency: ok [0.120330] Setting up static identity map for 0x803d5b28 - 0x803d5b80 [0.121856] devtmpfs: initialized [0.122680] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [0.138458] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [0.138977] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp [0.182159] omap_hwmod: mcbsp2: cannot be enabled for reset (3) [0.228424] pinctrl core: initialized pinctrl subsystem [0.259399] NET: Registered protocol family 16 [0.260131] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.288696] cpuidle: using governor ladder [0.318572] cpuidle: using governor menu [0.324981] Reprogramming SDRC clock to 16600 Hz [0.333160] OMAP GPIO hardware version 2.5 [0.340515] irq: no irq domain found for /ocp/pinmux@48002030 ! [0.356994] omap-gpmc 6e00.gpmc: GPMC revision 5.0 [0.360015] platform 48058000.ssi-controller: Cannot lookup hwmod 'ssi' [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() [0.366943] Modules linked in: [0.366973] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc2-DM+ #2 [0.366973] Hardware name: Generic OMAP36xx (Flattened Device Tree) [0.367004] Backtrace: [0.367034] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [0.367034] r6:c0213e50 r5:0009 r4: r3: [0.367065] [] (show_stack) from [] (dump_stack+0x24/0x28) [0.367095] [] (dump_stack) from [] (warn_slowpath_common+0x8c/0xb8) [0.367126] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) [0.367126] r8: r7: r6:04001b00 r5: r4:f8001400 [0.367156] [] (warn_slowpath_null) from [] (omap3_l3_app_irq+0x100/0x134) [0.367187] [] (omap3_l3_app_irq) from [] (handle_irq_event_percpu+0x80/0x148) [0.367218] r9:c3953e00 r8:0013 r7: r6: r5:c39581c0 r4:c39581c0 [0.367248] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x68/0x90) [0.367248] r10:c3856000 r9:8000 r8:c3803200 r7:0001 r6: r5:c39581c0 [0.367279] r4:c3953e00 [0.367279] [] (handle_irq_event) from [] (handle_level_irq+0xa4/0x160) [0.367309] r5: r4:c3953e00 [0.367309] [] (handle_level_irq) from [] (generic_handle_irq+0x34/0x44) [0.367340] r4:0013 r3:c005df2c [0.367370] [] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb0) [0.367370] r4:c055db00 r3:0106 [0.367401] [] (__handle_domain_irq) from [] (omap_intc_handle_irq+0xd0/0xd8) [0.367401] r8:6113 r7:000a r6:c05842c0 r5:c3857d00 r4:c055dd20 r3:c3857d00 [0.367431] [] (omap_intc_handle_irq) from [] (__irq_svc+0x40/0x74) [0.367431] Exception stack(0xc3857d00 to 0xc3857d48) [0.367462] 7d00: 001c 0001 c38b7e00 c0554a80 001c [0.367492] 7d20: 6113 8000 c3856000 c3857d74 c3857d28 c3857d48 c005e3c0 c005c8f8 [0.367492] 7d40: 4113 [0.367492] r7:c3857d34 r6: r5:4113 r4:c005c8f8 [0.367523] [] (__setup_irq) from [] (setup_irq+0x48/0x90) [0.367523] r8:2113 r7:c39ec400 r6:c0554a80 r5:001c r4:c38b7e00 [0.367553] [] (setup_irq) from [] (omap_system_dma_probe+0x224/0x2f8) [0.367584] r6:0600 r5:c057342c r4:001c r3:0030 [0.367614] [] (omap_system_dma_probe) from [] (platform_drv_probe+0x4c/0xac) [0.367614] r10: r9:c04ff5f0 r8: r7:fdfb r6:c0554a3c r5:c39ec410 [0.367645] r4:c05875f0 [0.367645] [] (platform_drv_probe) from [] (driver_probe_device+0x110/0x244) [0.367675] r7:c0554a3c r6: r5:c39ec410 r4:c05875f0 [0.367675] [] (driver_probe_device) from
