Hi -
I recently brought in v 15 (and then v 17) of the CMA patches on tilt-tracking and backported to tilt-3.1 in order to support Panda onboard camera.
Without any highmem, stuff is working great, but with HIGHMEM, inclusion of either v15 and v17 CMA consistently blows chunks during DMA init like this -->
[ 0.517761] Enabling ERRATA 751472 [ 0.521392] OMAP4: Map 0xafe00000 to 0xfe600000 for dram barrier [ 0.529510] print_constraints: dummy: [ 0.534973] NET: Registered protocol family 16 [ 0.550659] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.559082] pgd = c0004000 [ 0.561950] [00000000] *pgd=00000000 [ 0.565734] Internal error: Oops: 805 [#1] PREEMPT SMP [ 0.571136] Modules linked in: [ 0.574371] CPU: 0 Tainted: G W (3.1.0-panda_tilt-3.1+ #2) [ 0.581268] PC is at __memzero+0x24/0x80 [ 0.585388] LR is at 0x0 [ 0.588073] pc : [<c0298ea4>] lr : [<00000000>] psr: 20000013 [ 0.588104] sp : ef833f54 ip : 00000000 fp : 00000000 [ 0.600067] r10: c0838c80 r9 : 00000000 r8 : 00000000 [ 0.605560] r7 : ef833f84 r6 : c14ac000 r5 : 00040000 r4 : 00000000 [ 0.612335] r3 : 00000000 r2 : 00000000 r1 : 0003ffc0 r0 : 00000000 [ 0.619140] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.626770] Control: 10c5387f Table: 8000404a DAC: 00000015 [ 0.632751] Process swapper (pid: 1, stack limit = 0xef8322f8) [ 0.638854] Stack: (0xef833f54 to 0xef834000) [ 0.643432] 3f40: c001df04 c0d3c000 00040000 [ 0.651947] 3f60: 00000647 c001dfa4 c08910a4 00040000 0000045f 00000000 00000000 c0838cc0 [ 0.660461] 3f80: 00000000 00000000 c08710cc c08ed640 ef832000 c0008900 0000009f c009e3c8 [ 0.668975] 3fa0: 0000009f c0838c80 c00145ec 00393531 00000000 c0140000 00000000 c08abcf4 [ 0.677459] 3fc0: 0000019a c08710cc c087186c c00145ec 00000013 00000000 00000000 00000000 [ 0.685974] 3fe0: 00000000 c0834874 00000000 00000000 c08347e8 c00145ec 37a42f33 10139e95 [ 0.694488] Code: e52de004 e1a0c002 e1a0e002 e2511040 (a8a0500c) [ 0.700866] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.705749] Kernel panic - not syncing: Attempted to kill init! [ 0.711944] CPU1: stopping [ 0.714843] [<c001a524>] (unwind_backtrace+0x0/0xf8) from [<c000865c>] (do_IPI+0xf0/0x118) [ 0.723449] [<c000865c>] (do_IPI+0xf0/0x118) from [<c05d8ff4>] (__irq_svc+0x34/0xd0) [ 0.731506] Exception stack(0xef873f90 to 0xef873fd8) [ 0.736785] 3f80: ffffffed 00ce3000 ef873fd8 00000000 [ 0.745300] 3fa0: ef872000 c08ed704 c05e2a8c c0890754 c0890914 411fc092 00000000 00000000 [ 0.753814] 3fc0: 00000001 ef873fd8 c0014648 c001464c 60000113 ffffffff [ 0.760742] [<c05d8ff4>] (__irq_svc+0x34/0xd0) from [<c001464c>] (default_idle+0x24/0x28) [ 0.769256] [<c001464c>] (default_idle+0x24/0x28) from [<c001489c>] (cpu_idle+0xfc/0x11c) [ 0.777770] [<c001489c>] (cpu_idle+0xfc/0x11c) from [<805d1954>] (0x805d1954)
Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks.
If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4?
-Andy
Hello Andy,
On Tuesday, December 20, 2011 2:56 AM You wrote:
I recently brought in v 15 (and then v 17) of the CMA patches on tilt-tracking and backported to tilt-3.1 in order to support Panda onboard camera.
Without any highmem, stuff is working great, but with HIGHMEM, inclusion of either v15 and v17 CMA consistently blows chunks during DMA init like this -->
[ 0.517761] Enabling ERRATA 751472 [ 0.521392] OMAP4: Map 0xafe00000 to 0xfe600000 for dram barrier [ 0.529510] print_constraints: dummy: [ 0.534973] NET: Registered protocol family 16 [ 0.550659] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.559082] pgd = c0004000 [ 0.561950] [00000000] *pgd=00000000 [ 0.565734] Internal error: Oops: 805 [#1] PREEMPT SMP [ 0.571136] Modules linked in: [ 0.574371] CPU: 0 Tainted: G W (3.1.0-panda_tilt-3.1+ #2) [ 0.581268] PC is at __memzero+0x24/0x80 [ 0.585388] LR is at 0x0 [ 0.588073] pc : [<c0298ea4>] lr : [<00000000>] psr: 20000013 [ 0.588104] sp : ef833f54 ip : 00000000 fp : 00000000 [ 0.600067] r10: c0838c80 r9 : 00000000 r8 : 00000000 [ 0.605560] r7 : ef833f84 r6 : c14ac000 r5 : 00040000 r4 : 00000000 [ 0.612335] r3 : 00000000 r2 : 00000000 r1 : 0003ffc0 r0 : 00000000 [ 0.619140] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 0.626770] Control: 10c5387f Table: 8000404a DAC: 00000015 [ 0.632751] Process swapper (pid: 1, stack limit = 0xef8322f8) [ 0.638854] Stack: (0xef833f54 to 0xef834000) [ 0.643432] 3f40: c001df04 c0d3c000 00040000 [ 0.651947] 3f60: 00000647 c001dfa4 c08910a4 00040000 0000045f 00000000 00000000 c0838cc0 [ 0.660461] 3f80: 00000000 00000000 c08710cc c08ed640 ef832000 c0008900 0000009f c009e3c8 [ 0.668975] 3fa0: 0000009f c0838c80 c00145ec 00393531 00000000 c0140000 00000000 c08abcf4 [ 0.677459] 3fc0: 0000019a c08710cc c087186c c00145ec 00000013 00000000 00000000 00000000 [ 0.685974] 3fe0: 00000000 c0834874 00000000 00000000 c08347e8 c00145ec 37a42f33 10139e95 [ 0.694488] Code: e52de004 e1a0c002 e1a0e002 e2511040 (a8a0500c) [ 0.700866] ---[ end trace 1b75b31a2719ed1d ]--- [ 0.705749] Kernel panic - not syncing: Attempted to kill init! [ 0.711944] CPU1: stopping [ 0.714843] [<c001a524>] (unwind_backtrace+0x0/0xf8) from [<c000865c>] (do_IPI+0xf0/0x118) [ 0.723449] [<c000865c>] (do_IPI+0xf0/0x118) from [<c05d8ff4>] (__irq_svc+0x34/0xd0) [ 0.731506] Exception stack(0xef873f90 to 0xef873fd8) [ 0.736785] 3f80: ffffffed 00ce3000 ef873fd8 00000000 [ 0.745300] 3fa0: ef872000 c08ed704 c05e2a8c c0890754 c0890914 411fc092 00000000 00000000 [ 0.753814] 3fc0: 00000001 ef873fd8 c0014648 c001464c 60000113 ffffffff [ 0.760742] [<c05d8ff4>] (__irq_svc+0x34/0xd0) from [<c001464c>] (default_idle+0x24/0x28) [ 0.769256] [<c001464c>] (default_idle+0x24/0x28) from [<c001489c>] (cpu_idle+0xfc/0x11c) [ 0.777770] [<c001489c>] (cpu_idle+0xfc/0x11c) from [<805d1954>] (0x805d1954)
Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks.
If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4?
I'm aware of this issue, I hope to post a fix ASAP I finish some of my urgent bug fixing related to our project. In meantime I suggest using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split).
Best regards
On 12/20/2011 03:38 PM, Somebody in the thread at some point said:
Hi -
Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks.
If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4?
I'm aware of this issue, I hope to post a fix ASAP I finish some of my urgent bug fixing related to our project. In meantime I suggest using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split).
Thanks a lot for the helpful reply Marek.
I made a workaround hack earlier using CONFIG_ZONE_DMA to restrict it to the non-Himem area for DMA.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=patch...
but your suggestion is more elegant. I'm unsure of the ramifications of the 2G / 2G scheme so I'll give it a try later.
CMA is looking like it's going to be very cool... the camera driver wanted a 10MB allocation and before CMA patches, it looked intractably stuck with 2MB max... afterwards, no problemo.
-Andy
On Tuesday 20 December 2011, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of the 2G / 2G scheme so I'll give it a try later.
WFIW, the main reason why people don't want the 2G/2G split is to allow user space application to grow to 3GB instead of limiting them to 2GB per task. Most applications are fine with 2GB, but some can run out of address space and die a little sooner. However, those are typically the ones that really want a 64 bit machine anyway.
Arnd
Hello,
On Tuesday, December 20, 2011 4:45 PM Arnd Bergmann wrote:
On Tuesday 20 December 2011, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of the 2G / 2G scheme so I'll give it a try later.
WFIW, the main reason why people don't want the 2G/2G split is to allow user space application to grow to 3GB instead of limiting them to 2GB per task. Most applications are fine with 2GB, but some can run out of address space and die a little sooner. However, those are typically the ones that really want a 64 bit machine anyway.
I know, I just suggested it as a workaround of the current CMA initialization bug. The other temporary solution is to enable DMA zone and set it to some high value (like 512MiB).
Best regards
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the 3G/1G requirement in Android, seems odd to me.
Thanks, Xianghua
On Tue, Dec 20, 2011 at 10:48 AM, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Tue, 2011-12-20 at 15:44 +0800, Andy Green wrote:
but your suggestion is more elegant. I'm unsure of the ramifications of the 2G / 2G scheme so I'll give it a try later.
Android requires a 3G/1G split. (That may, or may not be relevent.)
-- Tixy
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 2011-12-20 at 12:45 -0600, Xianghua Xiao wrote:
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the 3G/1G requirement in Android, seems odd to me.
I think there are some user libraries (bionic?, dalvik?) which are hard coded to the addresses just below 0xc000000. Perhaps this is configurable, I don't know. I just know that when trying to bring up Linaro Android on Versatile Express I had problems until I realised the 3G/1G split was needed; other Android people then agreed that kernels need to use that memory arrangement.
Can any Android experts confirm this?
On Tue, Dec 20, 2011 at 07:16:56PM +0000, Jon Medhurst (Tixy) wrote:
On Tue, 2011-12-20 at 12:45 -0600, Xianghua Xiao wrote:
where does it mandate 3G/1G in Android?
we're planning to use 2G/2G split as well, but I'm unaware of the 3G/1G requirement in Android, seems odd to me.
I think there are some user libraries (bionic?, dalvik?) which are hard coded to the addresses just below 0xc000000. Perhaps this is configurable, I don't know. I just know that when trying to bring up Linaro Android on Versatile Express I had problems until I realised the 3G/1G split was needed; other Android people then agreed that kernels need to use that memory arrangement.
Can any Android experts confirm this?
I think it is a fairly hardcoded assumption. I think at one point the codeaurora.org Android source supported a flag to enable android to work on the 2G split. I don't know if it still is present, though.
David
-
Andy Green -
Arnd Bergmann -
David Brown -
Jon Medhurst (Tixy) -
Marek Szyprowski -
Xianghua Xiao