Hi Bero,
It is seen that latest bionic patches are causing Origen MM to crash, I just verified by removing the stream of bionic patches for optimization. There was a specific failure from memcpy(), this was due to 32 bit un-aligned address (Source Pointer) passed as an argument , this addess is obtained from mmap (device space)
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned above. I have not tried disabling NEON flag though.
With Regards, Annamalai
On 26 June 2012 23:11, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
Hi Bero,
It is seen that latest bionic patches are causing Origen MM to crash, I just verified by removing the stream of bionic patches for optimization. There was a specific failure from memcpy(), this was due to 32 bit un-aligned address (Source Pointer) passed as an argument , this addess is obtained from mmap (device space)
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned above. I have not tried disabling NEON flag though.
Hi Bero. Let me know if these are cortex-strings related and if I can help,
-- Michael
Hi Michael,
On 27 June 2012 00:09, Michael Hope michael.hope@linaro.org wrote:
On 26 June 2012 23:11, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned above. I have not tried disabling NEON flag though.
Hi Bero. Let me know if these are cortex-strings related and if I can help,
Yes, it seems cortex-strings related. The attached file is the current memcpy() implementation -- pretty much an exact copy of the cortex-strings one with a bit of Bionic glue.
I don't see anything wrong with it at a quick glance.
ttyl bero
On 27 June 2012 10:21, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
Hi Michael,
On 27 June 2012 00:09, Michael Hope michael.hope@linaro.org wrote:
On 26 June 2012 23:11, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned above. I have not tried disabling NEON flag though.
Hi Bero. Let me know if these are cortex-strings related and if I can help,
Yes, it seems cortex-strings related. The attached file is the current memcpy() implementation -- pretty much an exact copy of the cortex-strings one with a bit of Bionic glue.
Hi Annamalai. The new routine uses the hardware support for unaligned loads and stores which is fine on conventional memory. Is there something special about device memory on your SOC?
-- Michael
Hi Micheal,
The mmap is just a device impl. with remap pfn for dma_alloc_coherant memory. The pages are mapped to user space in mmap device routine, for further info need to dig into impl.
With Regards, Annamalai
On 26 June 2012 18:43, Michael Hope michael.hope@linaro.org wrote:
On 27 June 2012 10:21, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
Hi Michael,
On 27 June 2012 00:09, Michael Hope michael.hope@linaro.org wrote:
On 26 June 2012 23:11, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned
above.
I have not tried disabling NEON flag though.
Hi Bero. Let me know if these are cortex-strings related and if I can
help,
Yes, it seems cortex-strings related. The attached file is the current memcpy() implementation -- pretty much an exact copy of the cortex-strings one with a bit of Bionic glue.
Hi Annamalai. The new routine uses the hardware support for unaligned loads and stores which is fine on conventional memory. Is there something special about device memory on your SOC?
-- Michael
On 26 June 2012 21:55, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
Hi Micheal,
The mmap is just a device impl. with remap pfn for dma_alloc_coherant memory. The pages are mapped to user space in mmap device routine, for further info need to dig into impl.
Are you seeing a fault in user or kernel space Annamalai?
Also, Annmalai, would you file a bug for this, assign it to yourself and put it on the schedule this month?
With Regards, Annamalai
On 26 June 2012 18:43, Michael Hope michael.hope@linaro.org wrote:
On 27 June 2012 10:21, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
Hi Michael,
On 27 June 2012 00:09, Michael Hope michael.hope@linaro.org wrote:
On 26 June 2012 23:11, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
It looks like the latest optmizations are not taking this scenario into consideration and thus causing issues for specific case as mentioned above. I have not tried disabling NEON flag though.
Hi Bero. Let me know if these are cortex-strings related and if I can help,
Yes, it seems cortex-strings related. The attached file is the current memcpy() implementation -- pretty much an exact copy of the cortex-strings one with a bit of Bionic glue.
Hi Annamalai. The new routine uses the hardware support for unaligned loads and stores which is fine on conventional memory. Is there something special about device memory on your SOC?
-- Michael
linaro-android mailing list linaro-android@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android
On 27 June 2012 14:55, Annamalai Lakshmanan annamalai.lakshmanan@linaro.org wrote:
Hi Micheal,
The mmap is just a device impl. with remap pfn for dma_alloc_coherant memory. The pages are mapped to user space in mmap device routine, for further info need to dig into impl.
Hi Annamalai. Sorry for the delay in replying. ISO C doesn't guarantee the types of memory access that memcpy() uses. If the device memory has special properties such as not supporting unaligned access, then you should implement or use a different function.
See: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.htm...
for more.
-- Michael
linaro-android@lists.linaro.org