Passing mem=1G to kernel on Panda, system is unstable.

Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

Hi folks,

We are trying to build kernel package or GCC natively on OMAP4 panda
board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
kernel, we met same instabilities on the system when we try to use
mem=1G on the board.

Please find our bug tracker here:
https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
and I think another bug is also related:
https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370.
System will freeze at all when building GCC natively on Panda.

Did any folks meet this issue? or we need more simple test case to
catch the root cause of this issue.

Thanks a lot,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Paul Walmsley]

On Wed, 12 Jan 2011, Bryan Wu wrote:

> We are trying to build kernel package or GCC natively on OMAP4 panda
> board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
> kernel, we met same instabilities on the system when we try to use
> mem=1G on the board.
> 
> Please find our bug tracker here:
> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
> and I think another bug is also related:
> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370.
> System will freeze at all when building GCC natively on Panda.
> 
> Did any folks meet this issue? or we need more simple test case to
> catch the root cause of this issue.

Does the problem also happen if you boot with 'nosmp' on the kernel 
command line?


- Paul

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Wed, 12 Jan 2011, Bryan Wu wrote:
>
>> We are trying to build kernel package or GCC natively on OMAP4 panda
>> board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
>> kernel, we met same instabilities on the system when we try to use
>> mem=1G on the board.
>>
>> Please find our bug tracker here:
>> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
>> and I think another bug is also related:
>> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370.
>> System will freeze at all when building GCC natively on Panda.
>>
>> Did any folks meet this issue? or we need more simple test case to
>> catch the root cause of this issue.
>
> Does the problem also happen if you boot with 'nosmp' on the kernel
> command line?
>

Yeah, I think so, since Sebastien reported that 'nosmp' doesn't work either.

Thanks,
-Bryan

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Paul Walmsley]

On Thu, 13 Jan 2011, Bryan Wu wrote:

> On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Wed, 12 Jan 2011, Bryan Wu wrote:
> >
> > Does the problem also happen if you boot with 'nosmp' on the kernel
> > command line?
> 
> Yeah, I think so, since Sebastien reported that 'nosmp' doesn't work either.

Will try to find time to give this a shot.  You might want to try a build 
without CONFIG_SMP set to see if it helps.

Is the rootfs that you used downloadable from anywhere?


- Paul

RE: Passing mem=1G to kernel on Panda, system is unstable.

[Santosh Shilimkar]

Bryan,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Bryan Wu
> Sent: Tuesday, January 11, 2011 10:22 PM
> To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> Subject: Passing mem=1G to kernel on Panda, system is unstable.
>
> Hi folks,
>
> We are trying to build kernel package or GCC natively on OMAP4 panda
> board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
> kernel, we met same instabilities on the system when we try to use
> mem=1G on the board.
>
> Please find our bug tracker here:
> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
> and I think another bug is also related:
> https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> omap4/+bug/690370.
> System will freeze at all when building GCC natively on Panda.
>
> Did any folks meet this issue? or we need more simple test case to
> catch the root cause of this issue.
>
Haven't seen this issue on my SDP with 2.6.37.
Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?

RE: Passing mem=1G to kernel on Panda, system is unstable.

[Santosh Shilimkar]

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

> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Friday, January 14, 2011 1:43 PM
> To: Bryan Wu; linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> Subject: RE: Passing mem=1G to kernel on Panda, system is unstable.
>
> Bryan,
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Bryan Wu
> > Sent: Tuesday, January 11, 2011 10:22 PM
> > To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> > Subject: Passing mem=1G to kernel on Panda, system is unstable.
> >
> > Hi folks,
> >
> > We are trying to build kernel package or GCC natively on OMAP4
> panda
> > board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35
> based
> > kernel, we met same instabilities on the system when we try to use
> > mem=1G on the board.
> >
> > Please find our bug tracker here:
> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> omap4/+bug/633227
> > and I think another bug is also related:
> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> > omap4/+bug/690370.
> > System will freeze at all when building GCC natively on Panda.
> >
> > Did any folks meet this issue? or we need more simple test case to
> > catch the root cause of this issue.
> >
> Haven't seen this issue on my SDP with 2.6.37.
> Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?

This patch may not be relevant but last week while scanning
errata's I came across one which is applicable to OMAP4 ES2.x

Am attaching it. Please give a try. Have boot tested with latest
mainline tree.

Regards,
Santosh

[-- Attachment #2: 0001-ARM-l2x0-Errata-fix-for-flush-by-Way-operation-can.patch --]
[-- Type: application/octet-stream, Size: 3844 bytes --]

From 38406dbf0ed3f4b25369daea7d797292e00f3f0e Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [PATCH] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption

PL310 implements the Clean & Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.

Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/Kconfig            |   11 +++++++++++
 arch/arm/mach-omap2/Kconfig |    1 +
 arch/arm/mm/cache-l2x0.c    |   16 ++++++++++------
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9678ee5..a7dfc05 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1181,6 +1181,17 @@ config ARM_ERRATA_743622
 	  visible impact on the overall performance or power consumption of the
 	  processor.
 
+config PL310_ERRATA_727915
+	bool "Background Clean & Invalidate by Way operation can cause data corruption"
+	depends on CACHE_L2X0 && ARCH_OMAP4
+	help
+	  PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+	  operation (offset 0x7FC). This operation runs in background so that
+	  PL310 can handle normal accesses while it is in progress. Under very
+	  rare circumstances, due to this erratum, write data can be lost when
+	  PL310 treats a cacheable write transaction during a Clean &
+	  Invalidate by Way operation Note that this errata uses Texas
+	  Instrument's secure monitor api to implement the work around.
 endmenu
 
 source "arch/arm/common/Kconfig"
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d02a068..d6380a6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -46,6 +46,7 @@ config ARCH_OMAP4
 	select CPU_V7
 	select ARM_GIC
 	select PL310_ERRATA_588369
+	select PL310_ERRATA_727915 
 	select ARM_ERRATA_720789
 	select ARCH_HAS_OPP
 	select PM_OPP if PM
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 170c9bb..c7c8fbe 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -67,7 +67,7 @@ static inline void l2x0_inv_line(unsigned long addr)
 	writel_relaxed(addr, base + L2X0_INV_LINE_PA);
 }
 
-#ifdef CONFIG_PL310_ERRATA_588369
+#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
 static void debug_writel(unsigned long val)
 {
 	extern void omap_smc1(u32 fn, u32 arg);
@@ -78,7 +78,14 @@ static void debug_writel(unsigned long val)
 	 */
 	omap_smc1(0x100, val);
 }
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
+}
+#endif
 
+#ifdef CONFIG_PL310_ERRATA_588369
 static inline void l2x0_flush_line(unsigned long addr)
 {
 	void __iomem *base = l2x0_base;
@@ -91,11 +98,6 @@ static inline void l2x0_flush_line(unsigned long addr)
 }
 #else
 
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-
 static inline void l2x0_flush_line(unsigned long addr)
 {
 	void __iomem *base = l2x0_base;
@@ -119,9 +121,11 @@ static void l2x0_flush_all(void)
 
 	/* clean all ways */
 	spin_lock_irqsave(&l2x0_lock, flags);
+	debug_writel(0x03);
 	writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
 	cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
 	cache_sync();
+	debug_writel(0x00);
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-- 
1.6.0.4

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Fri, Jan 14, 2011 at 1:41 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Thu, 13 Jan 2011, Bryan Wu wrote:
>
>> On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> > On Wed, 12 Jan 2011, Bryan Wu wrote:
>> >
>> > Does the problem also happen if you boot with 'nosmp' on the kernel
>> > command line?
>>
>> Yeah, I think so, since Sebastien reported that 'nosmp' doesn't work either.
>
> Will try to find time to give this a shot.  You might want to try a build
> without CONFIG_SMP set to see if it helps.
>
Thanks a lot, man. Sebastien and I will try to disable CONFIG_SMP with
mainline kernel on Panda.

> Is the rootfs that you used downloadable from anywhere?
>
Please check this wiki page:
http://omappedia.org/wiki/Ubuntu_rootfs

I use following command to build a latest Natty (11.04) Ubuntu rootfs.
sudo rootstock -d natty -f ubuntu -l ubuntu -p ubuntu --serial ttyO2
--locale en_US.UTF-8 -s ubuntu-minimal,openssh-server,

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Fri, Jan 14, 2011 at 4:12 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Bryan,
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Bryan Wu
>> Sent: Tuesday, January 11, 2011 10:22 PM
>> To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
>> Subject: Passing mem=1G to kernel on Panda, system is unstable.
>>
>> Hi folks,
>>
>> We are trying to build kernel package or GCC natively on OMAP4 panda
>> board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
>> kernel, we met same instabilities on the system when we try to use
>> mem=1G on the board.
>>
>> Please find our bug tracker here:
>> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
>> and I think another bug is also related:
>> https://bugs.launchpad.net/ubuntu/+source/linux-ti-
>> omap4/+bug/690370.
>> System will freeze at all when building GCC natively on Panda.
>>
>> Did any folks meet this issue? or we need more simple test case to
>> catch the root cause of this issue.
>>
> Haven't seen this issue on my SDP with 2.6.37.
Do you have Panda for testing? I don't have SDP. Maybe Sebastien can
help to verify on SDP.

> Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?
>

Yeah, CONFIG_HIGHMEM=y for this mainline testing. Please use this
kernel config file:
http://launchpadlibrarian.net/62061659/mainline_config

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Fri, Jan 14, 2011 at 4:56 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
>> Sent: Friday, January 14, 2011 1:43 PM
>> To: Bryan Wu; linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
>> Subject: RE: Passing mem=1G to kernel on Panda, system is unstable.
>>
>> Bryan,
>> > -----Original Message-----
>> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> > owner@vger.kernel.org] On Behalf Of Bryan Wu
>> > Sent: Tuesday, January 11, 2011 10:22 PM
>> > To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
>> > Subject: Passing mem=1G to kernel on Panda, system is unstable.
>> >
>> > Hi folks,
>> >
>> > We are trying to build kernel package or GCC natively on OMAP4
>> panda
>> > board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35
>> based
>> > kernel, we met same instabilities on the system when we try to use
>> > mem=1G on the board.
>> >
>> > Please find our bug tracker here:
>> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
>> omap4/+bug/633227
>> > and I think another bug is also related:
>> > https://bugs.launchpad.net/ubuntu/+source/linux-ti-
>> > omap4/+bug/690370.
>> > System will freeze at all when building GCC natively on Panda.
>> >
>> > Did any folks meet this issue? or we need more simple test case to
>> > catch the root cause of this issue.
>> >
>> Haven't seen this issue on my SDP with 2.6.37.
>> Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?
>
> This patch may not be relevant but last week while scanning
> errata's I came across one which is applicable to OMAP4 ES2.x
>
> Am attaching it. Please give a try. Have boot tested with latest
> mainline tree.
>

No problem. I will try it later. Here is 4:15am, I'll try to sleep for a while.

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Jan, Sebastien]

On Fri, Jan 14, 2011 at 11:09 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> On Fri, Jan 14, 2011 at 1:41 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> On Thu, 13 Jan 2011, Bryan Wu wrote:
>>
>>> On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com> wrote:
>>> > On Wed, 12 Jan 2011, Bryan Wu wrote:
>>> >
>>> > Does the problem also happen if you boot with 'nosmp' on the kernel
>>> > command line?
>>>
>>> Yeah, I think so, since Sebastien reported that 'nosmp' doesn't work either.
>>
>> Will try to find time to give this a shot.  You might want to try a build
>> without CONFIG_SMP set to see if it helps.
>>
> Thanks a lot, man. Sebastien and I will try to disable CONFIG_SMP with
> mainline kernel on Panda.

I just tested with the 2.6.37 mainline kernel and Bryan config, and
can reproduce the issue with CONFIG_SMP disabled.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Passing mem=1G to kernel on Panda, system is unstable.

[Santosh Shilimkar]

Seb,
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Jan, Sebastien
> Sent: Friday, January 14, 2011 10:41 PM
> To: Bryan Wu
> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
> Araujo
> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>
> On Fri, Jan 14, 2011 at 11:09 AM, Bryan Wu <bryan.wu@canonical.com>
> wrote:
> > On Fri, Jan 14, 2011 at 1:41 PM, Paul Walmsley <paul@pwsan.com>
> wrote:
> >> On Thu, 13 Jan 2011, Bryan Wu wrote:
> >>
> >>> On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com>
> wrote:
> >>> > On Wed, 12 Jan 2011, Bryan Wu wrote:
> >>> >
> >>> > Does the problem also happen if you boot with 'nosmp' on the
> kernel
> >>> > command line?
> >>>
> >>> Yeah, I think so, since Sebastien reported that 'nosmp' doesn't
> work either.
> >>
> >> Will try to find time to give this a shot.  You might want to try
> a build
> >> without CONFIG_SMP set to see if it helps.
> >>
> > Thanks a lot, man. Sebastien and I will try to disable CONFIG_SMP
> with
> > mainline kernel on Panda.
>
> I just tested with the 2.6.37 mainline kernel and Bryan config, and
> can reproduce the issue with CONFIG_SMP disabled.
Can you try the patch I sent on the list as well ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Sat, Jan 15, 2011 at 1:22 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Seb,
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Jan, Sebastien
>> Sent: Friday, January 14, 2011 10:41 PM
>> To: Bryan Wu
>> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
>> Araujo
>> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>>
>> On Fri, Jan 14, 2011 at 11:09 AM, Bryan Wu <bryan.wu@canonical.com>
>> wrote:
>> > On Fri, Jan 14, 2011 at 1:41 PM, Paul Walmsley <paul@pwsan.com>
>> wrote:
>> >> On Thu, 13 Jan 2011, Bryan Wu wrote:
>> >>
>> >>> On Thu, Jan 13, 2011 at 7:50 AM, Paul Walmsley <paul@pwsan.com>
>> wrote:
>> >>> > On Wed, 12 Jan 2011, Bryan Wu wrote:
>> >>> >
>> >>> > Does the problem also happen if you boot with 'nosmp' on the
>> kernel
>> >>> > command line?
>> >>>
>> >>> Yeah, I think so, since Sebastien reported that 'nosmp' doesn't
>> work either.
>> >>
>> >> Will try to find time to give this a shot.  You might want to try
>> a build
>> >> without CONFIG_SMP set to see if it helps.
>> >>
>> > Thanks a lot, man. Sebastien and I will try to disable CONFIG_SMP
>> with
>> > mainline kernel on Panda.
>>
>> I just tested with the 2.6.37 mainline kernel and Bryan config, and
>> can reproduce the issue with CONFIG_SMP disabled.
> Can you try the patch I sent on the list as well ?

I've applied this patch to our Ubuntu Natty 2.6.35 based kernel, still
can reproduce the issue. But it looks to me this patch makes the
building run longer.

I'm testing the mainline 2.6.37 kernel + your patch here. I will let
you know the result soon.

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Jan, Sebastien]

Hi Santosh,

On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>>
>> I just tested with the 2.6.37 mainline kernel and Bryan config, and
>> can reproduce the issue with CONFIG_SMP disabled.
> Can you try the patch I sent on the list as well ?

Bryan is currently testing your patch. I have a build running with
HIGHMEM deactivated.

I'll also make a try on blaze board. I do not expect any difference
here. Note that the only way to trigger this issue for me was to make
native compilation of a big component (like native kernel
compilation).

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Sat, Jan 15, 2011 at 1:48 AM, Jan, Sebastien <s-jan@ti.com> wrote:
> Hi Santosh,
>
> On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>>
>>> I just tested with the 2.6.37 mainline kernel and Bryan config, and
>>> can reproduce the issue with CONFIG_SMP disabled.
>> Can you try the patch I sent on the list as well ?
>

Unfortunately, I still can reproduce this issue with mainline 2.6.37
kernel + the patch here:
---
[ 3391.102539] Unhandled fault: imprecise external abort (0x1406) at 0x4278f000
/home/ubuntu/ubuntu-natty/drivers/media/dvb/dvb-usb/a800.c:197:1:
internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.5/README.Bugs> for instructions.
---

-Bryan

> Bryan is currently testing your patch. I have a build running with
> HIGHMEM deactivated.
>
> I'll also make a try on blaze board. I do not expect any difference
> here. Note that the only way to trigger this issue for me was to make
> native compilation of a big component (like native kernel
> compilation).
>

RE: Passing mem=1G to kernel on Panda, system is unstable.

[Santosh Shilimkar]

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

> -----Original Message-----
> From: cooloney@gmail.com [mailto:cooloney@gmail.com] On Behalf Of
> Bryan Wu
> Sent: Saturday, January 15, 2011 12:11 AM
> To: Jan, Sebastien; Santosh Shilimkar
> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
> Araujo
> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>
> On Sat, Jan 15, 2011 at 1:48 AM, Jan, Sebastien <s-jan@ti.com>
> wrote:
> > Hi Santosh,
> >
> > On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> >>>
> >>> I just tested with the 2.6.37 mainline kernel and Bryan config,
> and
> >>> can reproduce the issue with CONFIG_SMP disabled.
> >> Can you try the patch I sent on the list as well ?
> >
>
> Unfortunately, I still can reproduce this issue with mainline 2.6.37
> kernel + the patch here:
I see.
Since it's undefined async abort.... Mostly some clock/module race.
I have one more experimental debug patch if you would like to
try out.

This patch just configures the interconnect space to SO instead of
device memory.

Regards,
Santosh

[-- Attachment #2: 0001-OMAP3-4-Diable-IO-posting.patch --]
[-- Type: application/octet-stream, Size: 7118 bytes --]

From b9166a203741800c1e5c30c7455d90f7d36fb4fc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sat, 7 Aug 2010 14:10:14 +0530
Subject: [PATCH] OMAP3/4: Diable IO posting

Selectable posting control for internal device registers
To enable IO posting select CONFIG_INTERCONNECT_IO_POSTING

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Richard Woodruff <r-woodruff2@ti.com>
---
 arch/arm/include/asm/mach/map.h      |    2 ++
 arch/arm/mach-omap2/Kconfig          |   11 +++++++++++
 arch/arm/mach-omap2/io.c             |   31 ++++++++++++++++---------------
 arch/arm/mm/mmu.c                    |   10 ++++++++++
 arch/arm/plat-omap/include/plat/io.h |   23 +++++++++++++++++++++++
 5 files changed, 62 insertions(+), 15 deletions(-)

diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..c9fcb79 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,8 @@ struct map_desc {
 #define MT_MEMORY_NONCACHED	11
 #define MT_MEMORY_DTCM		12
 #define MT_MEMORY_ITCM		13
+#define MT_MEMORY_SO		14
+#define MT_MEMORY_SO_EXE	15
 
 #ifdef CONFIG_MMU
 extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..44fb785 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -50,6 +50,17 @@ config ARCH_OMAP4
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI
 
+config INTERCONNECT_IO_POSTING
+        bool "Enable bus posting for PIO accesses"
+        depends on ARCH_OMAP34XX || ARCH_OMAP4
+        default n
+        ---help---
+        This option sets PIO access for internal OMAP3 registers to follow the
+        ARMv7 DEVICE attribute. For 3430 this will allow posted writes in the
+        interconnect. Software will need to synchronize writes to ensure
+        completion. When not set the attribute is Strongly Ordered which is
+        non-posted on the OMAP3 interconnect.
+
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
 
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index e66687b..c7eb79b 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -126,43 +126,43 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
 		.virtual	= L3_34XX_VIRT,
 		.pfn		= __phys_to_pfn(L3_34XX_PHYS),
 		.length		= L3_34XX_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_34XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_34XX_PHYS),
 		.length		= L4_34XX_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP34XX_GPMC_VIRT,
 		.pfn		= __phys_to_pfn(OMAP34XX_GPMC_PHYS),
 		.length		= OMAP34XX_GPMC_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP343X_SMS_VIRT,
 		.pfn		= __phys_to_pfn(OMAP343X_SMS_PHYS),
 		.length		= OMAP343X_SMS_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP343X_SDRC_VIRT,
 		.pfn		= __phys_to_pfn(OMAP343X_SDRC_PHYS),
 		.length		= OMAP343X_SDRC_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_PER_34XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_PER_34XX_PHYS),
 		.length		= L4_PER_34XX_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_EMU_34XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_EMU_34XX_PHYS),
 		.length		= L4_EMU_34XX_SIZE,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 #if defined(CONFIG_DEBUG_LL) &&							\
 	(defined(CONFIG_MACH_OMAP_ZOOM2) || defined(CONFIG_MACH_OMAP_ZOOM3))
@@ -170,7 +170,7 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
 		.virtual	= ZOOM_UART_VIRT,
 		.pfn		= __phys_to_pfn(ZOOM_UART_BASE),
 		.length		= SZ_1M,
-		.type		= MT_DEVICE
+		.type		= IO_MAP_TYPE
 	},
 #endif
 };
@@ -181,49 +181,50 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
 		.virtual	= L3_44XX_VIRT,
 		.pfn		= __phys_to_pfn(L3_44XX_PHYS),
 		.length		= L3_44XX_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_44XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_44XX_PHYS),
 		.length		= L4_44XX_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP44XX_GPMC_VIRT,
 		.pfn		= __phys_to_pfn(OMAP44XX_GPMC_PHYS),
 		.length		= OMAP44XX_GPMC_SIZE,
 		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP44XX_EMIF1_VIRT,
 		.pfn		= __phys_to_pfn(OMAP44XX_EMIF1_PHYS),
 		.length		= OMAP44XX_EMIF1_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP44XX_EMIF2_VIRT,
 		.pfn		= __phys_to_pfn(OMAP44XX_EMIF2_PHYS),
 		.length		= OMAP44XX_EMIF2_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= OMAP44XX_DMM_VIRT,
 		.pfn		= __phys_to_pfn(OMAP44XX_DMM_PHYS),
 		.length		= OMAP44XX_DMM_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_PER_44XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_PER_44XX_PHYS),
 		.length		= L4_PER_44XX_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 	{
 		.virtual	= L4_EMU_44XX_VIRT,
 		.pfn		= __phys_to_pfn(L4_EMU_44XX_PHYS),
 		.length		= L4_EMU_44XX_SIZE,
-		.type		= MT_DEVICE,
+		.type		= IO_MAP_TYPE
 	},
 };
 #endif
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 3c67e92..4e9f8d3 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -275,6 +275,16 @@ static struct mem_type mem_types[] = {
 		.prot_l1   = PMD_TYPE_TABLE,
 		.domain    = DOMAIN_KERNEL,
 	},
+	[MT_MEMORY_SO] = {
+		.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+				PMD_SECT_UNCACHED | PMD_SECT_XN,
+		.domain    = DOMAIN_KERNEL,
+	},
+	[MT_MEMORY_SO_EXE] = {
+		.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
+				PMD_SECT_UNCACHED,
+		.domain    = DOMAIN_KERNEL,
+	},
 };
 
 const struct mem_type *get_mem_type(unsigned int type)
diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h
index ef4106c..ee333a6 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -60,6 +60,17 @@
 #define IOMEM(x)		((void __force __iomem *)(x))
 #endif
 
+#ifdef CONFIG_INTERCONNECT_IO_POSTING
+ /*
+  * ARM writes to devices are postable.  Further software
+  * sychronization neeed ex: DSB or register read back
+  */
+ #define IO_MAP_TYPE    MT_DEVICE
+ #else
+ /* ARM writes to devices are sychronized */
+ #define IO_MAP_TYPE    MT_MEMORY_SO
+ #endif
+
 #define OMAP1_IO_OFFSET		0x01000000	/* Virtual IO = 0xfefb0000 */
 #define OMAP1_IO_ADDRESS(pa)	IOMEM((pa) - OMAP1_IO_OFFSET)
 
@@ -144,6 +155,18 @@
  * ----------------------------------------------------------------------------
  */
 
+/* Select ARM view IO behavior */
+#ifdef CONFIG_INTERCONNECT_IO_POSTING
+/*
+ * ARM writes to devices are postable.  Further software
+ * sychronization neeed ex: DSB or register read back
+ */
+#define IO_MAP_TYPE    MT_DEVICE
+#else
+/* ARM writes to devices are sychronized */
+#define IO_MAP_TYPE    MT_MEMORY_SO
+#endif
+
 /* We map both L3 and L4 on OMAP3 */
 #define L3_34XX_PHYS		L3_34XX_BASE	/* 0x68000000 --> 0xf8000000 */
 #define L3_34XX_VIRT		(L3_34XX_PHYS + OMAP2_L3_IO_OFFSET)
-- 
1.6.0.4

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Sat, Jan 15, 2011 at 2:55 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
>> -----Original Message-----
>> From: cooloney@gmail.com [mailto:cooloney@gmail.com] On Behalf Of
>> Bryan Wu
>> Sent: Saturday, January 15, 2011 12:11 AM
>> To: Jan, Sebastien; Santosh Shilimkar
>> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
>> Araujo
>> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>>
>> On Sat, Jan 15, 2011 at 1:48 AM, Jan, Sebastien <s-jan@ti.com>
>> wrote:
>> > Hi Santosh,
>> >
>> > On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
>> > <santosh.shilimkar@ti.com> wrote:
>> >>>
>> >>> I just tested with the 2.6.37 mainline kernel and Bryan config,
>> and
>> >>> can reproduce the issue with CONFIG_SMP disabled.
>> >> Can you try the patch I sent on the list as well ?
>> >
>>
>> Unfortunately, I still can reproduce this issue with mainline 2.6.37
>> kernel + the patch here:
> I see.
> Since it's undefined async abort.... Mostly some clock/module race.
> I have one more experimental debug patch if you would like to
> try out.
>
> This patch just configures the interconnect space to SO instead of
> device memory.
>

No problem, I will try this soon.

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Bryan Wu]

On Sat, Jan 15, 2011 at 3:06 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> On Sat, Jan 15, 2011 at 2:55 AM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>>> -----Original Message-----
>>> From: cooloney@gmail.com [mailto:cooloney@gmail.com] On Behalf Of
>>> Bryan Wu
>>> Sent: Saturday, January 15, 2011 12:11 AM
>>> To: Jan, Sebastien; Santosh Shilimkar
>>> Cc: Paul Walmsley; linux-omap@vger.kernel.org; Ricardo Salveti de
>>> Araujo
>>> Subject: Re: Passing mem=1G to kernel on Panda, system is unstable.
>>>
>>> On Sat, Jan 15, 2011 at 1:48 AM, Jan, Sebastien <s-jan@ti.com>
>>> wrote:
>>> > Hi Santosh,
>>> >
>>> > On Fri, Jan 14, 2011 at 6:22 PM, Santosh Shilimkar
>>> > <santosh.shilimkar@ti.com> wrote:
>>> >>>
>>> >>> I just tested with the 2.6.37 mainline kernel and Bryan config,
>>> and
>>> >>> can reproduce the issue with CONFIG_SMP disabled.
>>> >> Can you try the patch I sent on the list as well ?
>>> >
>>>
>>> Unfortunately, I still can reproduce this issue with mainline 2.6.37
>>> kernel + the patch here:
>> I see.
>> Since it's undefined async abort.... Mostly some clock/module race.
>> I have one more experimental debug patch if you would like to
>> try out.
>>
>> This patch just configures the interconnect space to SO instead of
>> device memory.
>>

I applied this patch to 2.6.37 kernel and try the kernel again, still
got the same bus error with this patch.

for the clock/module race, do you have any simpler test case to
generate this issue than building a whole kernel package.

Thanks,
-- 
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Passing mem=1G to kernel on Panda, system is unstable.

[Jan, Sebastien]

On Fri, Jan 14, 2011 at 11:12 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
>
> On Fri, Jan 14, 2011 at 4:12 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
> > Bryan,
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> >> owner@vger.kernel.org] On Behalf Of Bryan Wu
> >> Sent: Tuesday, January 11, 2011 10:22 PM
> >> To: linux-omap@vger.kernel.org; Ricardo Salveti de Araujo
> >> Subject: Passing mem=1G to kernel on Panda, system is unstable.
> >>
> >> Hi folks,
> >>
> >> We are trying to build kernel package or GCC natively on OMAP4 panda
> >> board. With the mainline 2.6.37 kernel or Ubuntu Natty 2.6.35 based
> >> kernel, we met same instabilities on the system when we try to use
> >> mem=1G on the board.
> >>
> >> Please find our bug tracker here:
> >> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227
> >> and I think another bug is also related:
> >> https://bugs.launchpad.net/ubuntu/+source/linux-ti-
> >> omap4/+bug/690370.
> >> System will freeze at all when building GCC natively on Panda.
> >>
> >> Did any folks meet this issue? or we need more simple test case to
> >> catch the root cause of this issue.
> >>
> > Haven't seen this issue on my SDP with 2.6.37.
> Do you have Panda for testing? I don't have SDP. Maybe Sebastien can
> help to verify on SDP.

I reproduced the issue on my Blaze board, confirming that this issue
is not specific to panda.

> > Have you enabled HIGHMEM, when tried mem = 1G on 2.6.37 ?
> >
>
> Yeah, CONFIG_HIGHMEM=y for this mainline testing. Please use this
> kernel config file:
> http://launchpadlibrarian.net/62061659/mainline_config

So far, I have not been able to reproduce the issue with
CONFIG_HIGHMEM option deactivated (I am cleaning/building kernels for
more than 24 hours now), and mem=1G. I will keep my test run, but it
seems that deactivating highmem at least hides the issue.