FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 09-24-2010, 03:45 AM
Ricardo Salveti de Araujo
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Fri, Sep 24, 2010 at 11:21:01AM +0800, Bryan Wu wrote:
> SRU Justification:
>
> Impact:
> There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When we
> build kernel package natively on ES2.0 platform with mem=1G and highmem
> enabled, we will meet 'Bus Error' corruption from gcc shortly. And 'Unhandled
> imprecised external abort' kernel oops messages. Then the whole system will be
> very instable.
>
> Fix: After some debugging, this issue is related to highmem. If we don't use
> mem=1G (no memory in highmem), the corruption is gone. So there is a workaround
> which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G instead
> of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
> memory in highmem. As a result, the issue is gone.

Generally when using highmem we can reproduce this issue quickly, with 10, 15
minutes after started the kernel build. Currently without highmem I was able to
build the whole kernel 3 times already, and didn't face this issue.

I just started another batch that will run at least more 5 times during this
night, and will reply tomorrow with the test result.

Meanwhile we're debugging the highmem issue with Nicolas's help.

Cheers,
--
Ricardo Salveti de Araujo

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-24-2010, 06:04 AM
Ricardo Salveti de Araujo
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Fri, Sep 24, 2010 at 12:45:30AM -0300, Ricardo Salveti de Araujo wrote:
> On Fri, Sep 24, 2010 at 11:21:01AM +0800, Bryan Wu wrote:
> > SRU Justification:
> >
> > Impact:
> > There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When we
> > build kernel package natively on ES2.0 platform with mem=1G and highmem
> > enabled, we will meet 'Bus Error' corruption from gcc shortly. And 'Unhandled
> > imprecised external abort' kernel oops messages. Then the whole system will be
> > very instable.
> >
> > Fix: After some debugging, this issue is related to highmem. If we don't use
> > mem=1G (no memory in highmem), the corruption is gone. So there is a workaround
> > which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G instead
> > of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
> > memory in highmem. As a result, the issue is gone.
>
> Generally when using highmem we can reproduce this issue quickly, with 10, 15
> minutes after started the kernel build. Currently without highmem I was able to
> build the whole kernel 3 times already, and didn't face this issue.
>
> I just started another batch that will run at least more 5 times during this
> night, and will reply tomorrow with the test result.
>
> Meanwhile we're debugging the highmem issue with Nicolas's help.

Unfortunatelly something else doesn't seems to be right :-(
After building it one time successfully with -j 2 I changed to -j 3 and after 10
minutes I got the following error:

Bad mode in data abort handler detected
Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/net/lo/type
Modules linked in: twl4030_pwrbutton sg usb_storage
CPU: 0 Not tainted (2.6.35.3+ #52)
PC is at 0xffff0010
LR is at 0x2abab896
pc : [<ffff0010>] lr : [<2abab896>] psr: 00000097
sp : bffcffb0 ip : 00000000 fp : 000b2de4
r10: 00000000 r9 : 000ac68c r8 : 00000050
r7 : 00000022 r6 : 004c7108 r5 : 0008cab0 r4 : ca797762
r3 : 004d6a68 r2 : 00000037 r1 : 0008cab0 r0 : 00000038
Flags: nzcv IRQs off FIQs on Mode ABT_32 ISA ARM Segment user
Control: 10c53c7d Table: bfffc04a DAC: 00000015
Process dhclient-script (pid: 6199, stack limit = 0xbffce2f8)
Stack: (0xbffcffb0 to 0xbffd0000)
ffa0: 00000038 0008cab0 00000037 004d6a68
ffc0: ca797762 0008cab0 004c7108 00000022 00000050 000ac68c 00000000 000b2de4
ffe0: 00000000 bffcffb0 2abab896 ffff0010 00000097 ffffffff 8102a021 8102a421
Code: ef9f0000 ea0000dd e59ff410 ea0000bb (ea00009a)

And at the userspace side I got a segfault in GCC instead of a bus error.

Kernel boot log to show that highmem is not being used:
Kernel command line: splash ro elevator=noop vram=32M root=/dev/sda5 fixrtc console=ttyO2,115200 mem=1G earlyprintk=ttyO2 omapdss.debug=1 loglevel=8 user_debug=16
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
allocated 5242880 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 1024MB = 1024MB total
Memory: 975176k/975176k available, 73400k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xc0800000 - 0xf8000000 ( 888 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x8003f000 ( 220 kB)
.text : 0x8003f000 - 0x806ef000 (6848 kB)
.data : 0x80728000 - 0x80798180 ( 449 kB)

Will also test it with only one cpu to see if this could be realted with SMP
issues.

And as reference, I'm testing this on a Panda ES2 8 layers.

Cheers,
--
Ricardo Salveti de Araujo

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-24-2010, 07:50 AM
Tim Gardner
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On 09/24/2010 11:21 AM, Bryan Wu wrote:
> SRU Justification:
>
> Impact:
> There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When we
> build kernel package natively on ES2.0 platform with mem=1G and highmem
> enabled, we will meet 'Bus Error' corruption from gcc shortly. And 'Unhandled
> imprecised external abort' kernel oops messages. Then the whole system will be
> very instable.
>
> Fix: After some debugging, this issue is related to highmem. If we don't use
> mem=1G (no memory in highmem), the corruption is gone. So there is a workaround
> which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G instead
> of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
> memory in highmem. As a result, the issue is gone.
>
> Testcase: Add kernel boot command line mem=1G, build kernel package on ES2.0
> hardware after booting the kernel. The issue is supposed to be gone with 2G:2G
> split config.
>
> A testing kernel is also here:
> http://people.canonical.com/~roc/kernel/lp633227/
>
> Notes: the VMALLOC_END value is wrong in mach-omap2, Nicolas Pitre posted a fixing
> patch to upstream, which is required in this workaround.
>
> BugLink: http://bugs.launchpad.net/bugs/#633227
>
> Plese consider pull from
> git://kernel.ubuntu.com/roc/ubuntu-maverick lp633227
>
> Bryan Wu (1):
> UBUNTU: [Config] Enable CONFIG_VMSPLIT_2G=y for OMAP4
>
> Nicolas Pitre (1):
> ARM: do not define VMALLOC_END relative to PAGE_OFFSET
>
> arch/arm/mach-aaec2000/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-bcmring/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-clps711x/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-ebsa110/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-footbridge/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-h720x/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-integrator/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-msm/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-netx/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-omap1/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-omap2/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-pnx4008/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-rpc/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-shark/include/mach/vmalloc.h | 2 +-
> arch/arm/mach-versatile/include/mach/vmalloc.h | 2 +-
> debian.ti-omap4/config/config.common.ubuntu | 6 +++---
> 16 files changed, 18 insertions(+), 18 deletions(-)
>

So, what do you want me to do? Ricardo is saying this workaround is not
sufficient.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-24-2010, 08:07 AM
Bryan Wu
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Fri, Sep 24, 2010 at 3:50 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> On 09/24/2010 11:21 AM, Bryan Wu wrote:
>>
>> SRU Justification:
>>
>> Impact:
>> There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When
>> we
>> build kernel package natively on ES2.0 platform with mem=1G and highmem
>> enabled, we will meet 'Bus Error' corruption from gcc shortly. And
>> 'Unhandled
>> imprecised external abort' kernel oops messages. Then the whole system
>> will be
>> very instable.
>>
>> Fix: After some debugging, this issue is related to highmem. If we don't
>> use
>> mem=1G (no memory in highmem), the corruption is gone. So there is a
>> workaround
>> which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G
>> instead
>> of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
>> memory in highmem. As a result, the issue is gone.
>>
>> Testcase: Add kernel boot command line mem=1G, build kernel package on
>> ES2.0
>> hardware after booting the kernel. The issue is supposed to be gone with
>> 2G:2G
>> split config.
>>
>> A testing kernel is also here:
>> http://people.canonical.com/~roc/kernel/lp633227/
>>
>> Notes: the VMALLOC_END value is wrong in mach-omap2, Nicolas Pitre posted
>> a fixing
>> patch to upstream, which is required in this workaround.
>>
>> BugLink: http://bugs.launchpad.net/bugs/#633227
>>
>> Plese consider pull from
>> *git://kernel.ubuntu.com/roc/ubuntu-maverick lp633227
>>
>> Bryan Wu (1):
>> * UBUNTU: [Config] Enable CONFIG_VMSPLIT_2G=y for OMAP4
>>
>> Nicolas Pitre (1):
>> * ARM: do not define VMALLOC_END relative to PAGE_OFFSET
>>
>> *arch/arm/mach-aaec2000/include/mach/vmalloc.h * | * *2 +-
>> *arch/arm/mach-bcmring/include/mach/vmalloc.h * *| * *2 +-
>> *arch/arm/mach-clps711x/include/mach/vmalloc.h * | * *2 +-
>> *arch/arm/mach-ebsa110/include/mach/vmalloc.h * *| * *2 +-
>> *arch/arm/mach-footbridge/include/mach/vmalloc.h | * *2 +-
>> *arch/arm/mach-h720x/include/mach/vmalloc.h * * *| * *2 +-
>> *arch/arm/mach-integrator/include/mach/vmalloc.h | * *2 +-
>> *arch/arm/mach-msm/include/mach/vmalloc.h * * * *| * *2 +-
>> *arch/arm/mach-netx/include/mach/vmalloc.h * * * | * *2 +-
>> *arch/arm/mach-omap1/include/mach/vmalloc.h * * *| * *2 +-
>> *arch/arm/mach-omap2/include/mach/vmalloc.h * * *| * *2 +-
>> *arch/arm/mach-pnx4008/include/mach/vmalloc.h * *| * *2 +-
>> *arch/arm/mach-rpc/include/mach/vmalloc.h * * * *| * *2 +-
>> *arch/arm/mach-shark/include/mach/vmalloc.h * * *| * *2 +-
>> *arch/arm/mach-versatile/include/mach/vmalloc.h *| * *2 +-
>> *debian.ti-omap4/config/config.common.ubuntu * * | * *6 +++---
>> *16 files changed, 18 insertions(+), 18 deletions(-)
>>
>
> So, what do you want me to do? Ricardo is saying this workaround is not
> sufficient.
>

Please ignore this pull request. We are working on it.

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-24-2010, 08:39 AM
"Dechesne, Nicolas"
 
Default SRU: A workaround for highmem issue on OMAP4 platform

Bryan, Ricardo,

before 'acking' this patch, we will need to run OMAP4 video use cases too. As you know OMAP4 has a custom coprocessor for video encode/decode which is sharing memory with the main core running Linux. We never tested the 2G/2G split for video use cases, and I cannot claim whether it's safe or not without doing more testing.

For sure building the kernel is a good testcase, but we need video use cases to be functional too.

nicolas


> On Fri, Sep 24, 2010 at 3:50 PM, Tim Gardner<tim.gardner@canonical.com> wrote:
>> On 09/24/2010 11:21 AM, Bryan Wu wrote:
>>>
>>> SRU Justification:
>>>
>>> Impact:
>>> There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When
>>> we
>>> build kernel package natively on ES2.0 platform with mem=1G and highmem
>>> enabled, we will meet 'Bus Error' corruption from gcc shortly. And
>>> 'Unhandled
>>> imprecised external abort' kernel oops messages. Then the whole system
>>> will be
>>> very instable.
>>>
>>> Fix: After some debugging, this issue is related to highmem. If we don't
>>> use
>>> mem=1G (no memory in highmem), the corruption is gone. So there is a
>>> workaround
>>> which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G
>>> instead
>>> of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
>>> memory in highmem. As a result, the issue is gone.
>>>
>>> Testcase: Add kernel boot command line mem=1G, build kernel package on
>>> ES2.0
>>> hardware after booting the kernel. The issue is supposed to be gone with
>>> 2G:2G
>>> split config.
>>>
>>> A testing kernel is also here:
>>> http://people.canonical.com/~roc/kernel/lp633227/
>>>
>>> Notes: the VMALLOC_END value is wrong in mach-omap2, Nicolas Pitre posted
>>> a fixing
>>> patch to upstream, which is required in this workaround.
>>>
>>> BugLink: http://bugs.launchpad.net/bugs/#633227
>>>
>>> Plese consider pull from
>>> git://kernel.ubuntu.com/roc/ubuntu-maverick lp633227
>>>
>>> Bryan Wu (1):
>>> UBUNTU: [Config] Enable CONFIG_VMSPLIT_2G=y for OMAP4
>>>
>>> Nicolas Pitre (1):
>>> ARM: do not define VMALLOC_END relative to PAGE_OFFSET
>>>
>>> arch/arm/mach-aaec2000/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-bcmring/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-clps711x/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-ebsa110/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-footbridge/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-h720x/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-integrator/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-msm/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-netx/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-omap1/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-omap2/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-pnx4008/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-rpc/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-shark/include/mach/vmalloc.h | 2 +-
>>> arch/arm/mach-versatile/include/mach/vmalloc.h | 2 +-
>>> debian.ti-omap4/config/config.common.ubuntu | 6 +++---
>>> 16 files changed, 18 insertions(+), 18 deletions(-)
>>>
>>
>> So, what do you want me to do? Ricardo is saying this workaround is not
>> sufficient.
>>
>
> Please ignore this pull request. We are working on it.
>
> Thanks,

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-24-2010, 06:03 PM
Nicolas Pitre
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Fri, 24 Sep 2010, Ricardo Salveti de Araujo wrote:

> On Fri, Sep 24, 2010 at 12:45:30AM -0300, Ricardo Salveti de Araujo wrote:
> > On Fri, Sep 24, 2010 at 11:21:01AM +0800, Bryan Wu wrote:
> > > SRU Justification:
> > >
> > > Impact:
> > > There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When we
> > > build kernel package natively on ES2.0 platform with mem=1G and highmem
> > > enabled, we will meet 'Bus Error' corruption from gcc shortly. And 'Unhandled
> > > imprecised external abort' kernel oops messages. Then the whole system will be
> > > very instable.
> > >
> > > Fix: After some debugging, this issue is related to highmem. If we don't use
> > > mem=1G (no memory in highmem), the corruption is gone. So there is a workaround
> > > which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G instead
> > > of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
> > > memory in highmem. As a result, the issue is gone.
> >
> > Generally when using highmem we can reproduce this issue quickly, with 10, 15
> > minutes after started the kernel build. Currently without highmem I was able to
> > build the whole kernel 3 times already, and didn't face this issue.
> >
> > I just started another batch that will run at least more 5 times during this
> > night, and will reply tomorrow with the test result.
> >
> > Meanwhile we're debugging the highmem issue with Nicolas's help.

Regardless of the issue, I suggest that my patch fixing the VMALLOC_END
be merged. Without it, the CONFIG_VMSPLIT_2G option is simply totally
useless.

> Unfortunatelly something else doesn't seems to be right :-(
> After building it one time successfully with -j 2 I changed to -j 3 and after 10
> minutes I got the following error:
>
> Bad mode in data abort handler detected
> Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP

Oooooh! Here's what the source code has to say about this:

/*
* bad_mode handles the impossible case in the vectors. If you see one of
* these, then it's extremely serious, and could mean you have buggy hardware.
* It never returns, and never tries to sync. We hope that we can at least
* dump out some state information...
*/

The only way this can happen is to get an exception while still in the
exception entry path for a previous exception. Needless to say that
this should normally be _impossible_.


Nicolas

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-26-2010, 06:05 AM
Ricardo Salveti de Araujo
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Fri, Sep 24, 2010 at 03:04:10AM -0300, Ricardo Salveti de Araujo wrote:
> On Fri, Sep 24, 2010 at 12:45:30AM -0300, Ricardo Salveti de Araujo wrote:
> > On Fri, Sep 24, 2010 at 11:21:01AM +0800, Bryan Wu wrote:
> > > SRU Justification:
> > >
> > > Impact:
> > > There is a critical highmem issue on our latest OMAP4 ES2.0 platform. When we
> > > build kernel package natively on ES2.0 platform with mem=1G and highmem
> > > enabled, we will meet 'Bus Error' corruption from gcc shortly. And 'Unhandled
> > > imprecised external abort' kernel oops messages. Then the whole system will be
> > > very instable.
> > >
> > > Fix: After some debugging, this issue is related to highmem. If we don't use
> > > mem=1G (no memory in highmem), the corruption is gone. So there is a workaround
> > > which is CONFIG_VMSPLIT_2G=y. So user and kernel memory split is 2G:2G instead
> > > of default 3G:1G. We can use all the 1G memory on ES2.0, but don't put any
> > > memory in highmem. As a result, the issue is gone.
> >
> > Generally when using highmem we can reproduce this issue quickly, with 10, 15
> > minutes after started the kernel build. Currently without highmem I was able to
> > build the whole kernel 3 times already, and didn't face this issue.
> >
> > I just started another batch that will run at least more 5 times during this
> > night, and will reply tomorrow with the test result.
> >
> > Meanwhile we're debugging the highmem issue with Nicolas's help.
>
> Unfortunatelly something else doesn't seems to be right :-(
> After building it one time successfully with -j 2 I changed to -j 3 and after 10
> minutes I got the following error:
>
> Bad mode in data abort handler detected
> Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
> last sysfs file: /sys/devices/virtual/net/lo/type
> Modules linked in: twl4030_pwrbutton sg usb_storage
> CPU: 0 Not tainted (2.6.35.3+ #52)
> PC is at 0xffff0010
> LR is at 0x2abab896
> pc : [<ffff0010>] lr : [<2abab896>] psr: 00000097
> sp : bffcffb0 ip : 00000000 fp : 000b2de4
> r10: 00000000 r9 : 000ac68c r8 : 00000050
> r7 : 00000022 r6 : 004c7108 r5 : 0008cab0 r4 : ca797762
> r3 : 004d6a68 r2 : 00000037 r1 : 0008cab0 r0 : 00000038
> Flags: nzcv IRQs off FIQs on Mode ABT_32 ISA ARM Segment user
> Control: 10c53c7d Table: bfffc04a DAC: 00000015
> Process dhclient-script (pid: 6199, stack limit = 0xbffce2f8)
> Stack: (0xbffcffb0 to 0xbffd0000)
> ffa0: 00000038 0008cab0 00000037 004d6a68
> ffc0: ca797762 0008cab0 004c7108 00000022 00000050 000ac68c 00000000 000b2de4
> ffe0: 00000000 bffcffb0 2abab896 ffff0010 00000097 ffffffff 8102a021 8102a421
> Code: ef9f0000 ea0000dd e59ff410 ea0000bb (ea00009a)
>
> And at the userspace side I got a segfault in GCC instead of a bus error.
>
> Kernel boot log to show that highmem is not being used:
> Kernel command line: splash ro elevator=noop vram=32M root=/dev/sda5 fixrtc console=ttyO2,115200 mem=1G earlyprintk=ttyO2 omapdss.debug=1 loglevel=8 user_debug=16
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> allocated 5242880 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> Memory: 1024MB = 1024MB total
> Memory: 975176k/975176k available, 73400k reserved, 0K highmem
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
> vmalloc : 0xc0800000 - 0xf8000000 ( 888 MB)
> lowmem : 0x80000000 - 0xc0000000 (1024 MB)
> pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
> modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
> .init : 0x80008000 - 0x8003f000 ( 220 kB)
> .text : 0x8003f000 - 0x806ef000 (6848 kB)
> .data : 0x80728000 - 0x80798180 ( 449 kB)
>
> Will also test it with only one cpu to see if this could be realted with SMP
> issues.

Ok, tested the same kernel but running with only one CPU, for 40 hours (what gave me
15 builds), and went all fine, without any errors at both userspace and kernelspace.

So it seems that this data abort exception could be related with concurrency and
SMP support at our kernel.

Cheers,
--
Ricardo Salveti de Araujo

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-26-2010, 03:01 PM
Nicolas Pitre
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Sun, 26 Sep 2010, Ricardo Salveti de Araujo wrote:

> On Fri, Sep 24, 2010 at 03:04:10AM -0300, Ricardo Salveti de Araujo wrote:
> > Will also test it with only one cpu to see if this could be realted with SMP
> > issues.
>
> Ok, tested the same kernel but running with only one CPU, for 40 hours (what gave me
> 15 builds), and went all fine, without any errors at both userspace and kernelspace.
>
> So it seems that this data abort exception could be related with concurrency and
> SMP support at our kernel.

Right. So I'd suggest you keep highmem off, and 2g:2g on (with the
VMALLOC_END fix), then try to reliably reproduce the issue with that
configuration and fix it before involving highmem again. While highmem
may make the problem more visible, it also brings a set of added
complexity of its own which would make the tracking of the issue much
harder.


Nicolas

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 09-26-2010, 03:38 PM
Bryan Wu
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Sun, Sep 26, 2010 at 11:01 PM, Nicolas Pitre
<nicolas.pitre@canonical.com> wrote:
> On Sun, 26 Sep 2010, Ricardo Salveti de Araujo wrote:
>
>> On Fri, Sep 24, 2010 at 03:04:10AM -0300, Ricardo Salveti de Araujo wrote:
>> > Will also test it with only one cpu to see if this could be realted with SMP
>> > issues.
>>
>> Ok, tested the same kernel but running with only one CPU, for 40 hours (what gave me
>> 15 builds), and went all fine, without any errors at both userspace and kernelspace.
>>
>> So it seems that this data abort exception could be related with concurrency and
>> SMP support at our kernel.
>
> Right. *So I'd suggest you keep highmem off, and 2g:2g on (with the
> VMALLOC_END fix), then try to reliably reproduce the issue with that
> configuration and fix it before involving highmem again. *While highmem
> may make the problem more visible, it also brings a set of added
> complexity of its own which would make the tracking of the issue much
> harder.
>
>
> Nicolas
>

I disabled CONFIG_CACHE_L2X0 L2 cache controller for omap4. So far for
the SMP kernel with mem=1G, kernel building is running correctly.
I will test more. It looks like L2 cache controlling has some issue.
 
Old 09-26-2010, 04:31 PM
Nicolas Pitre
 
Default SRU: A workaround for highmem issue on OMAP4 platform

On Sun, 26 Sep 2010, Bryan Wu wrote:

> On Sun, Sep 26, 2010 at 11:01 PM, Nicolas Pitre
> <nicolas.pitre@canonical.com> wrote:
> > On Sun, 26 Sep 2010, Ricardo Salveti de Araujo wrote:
> >
> >> On Fri, Sep 24, 2010 at 03:04:10AM -0300, Ricardo Salveti de Araujo wrote:
> >> > Will also test it with only one cpu to see if this could be realted with SMP
> >> > issues.
> >>
> >> Ok, tested the same kernel but running with only one CPU, for 40 hours (what gave me
> >> 15 builds), and went all fine, without any errors at both userspace and kernelspace.
> >>
> >> So it seems that this data abort exception could be related with concurrency and
> >> SMP support at our kernel.
> >
> > Right. *So I'd suggest you keep highmem off, and 2g:2g on (with the
> > VMALLOC_END fix), then try to reliably reproduce the issue with that
> > configuration and fix it before involving highmem again. *While highmem
> > may make the problem more visible, it also brings a set of added
> > complexity of its own which would make the tracking of the issue much
> > harder.
> >
> >
> > Nicolas
> >
>
> I disabled CONFIG_CACHE_L2X0 L2 cache controller for omap4. So far for
> the SMP kernel with mem=1G, kernel building is running correctly.
> I will test more. It looks like L2 cache controlling has some issue.

That's with or without highmem involved?


Nicolas--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 09:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org