From: bill4carson@gmail.com (bill4carson)
To: linux-arm-kernel@lists.infradead.org
Subject: Query about: ARM11 MPCore: preemption/task migration cache coherency
Date: Tue, 29 May 2012 13:28:11 +0800 [thread overview]
Message-ID: <4FC45E6B.2070202@gmail.com> (raw)
In-Reply-To: <20120511085150.GA17453@mudshark.cambridge.arm.com>
On 2012?05?11? 16:51, Will Deacon wrote:
> Bill,
>
> On Wed, May 09, 2012 at 10:11:05AM +0100, bill4carson wrote:
>> I'm using ARM11 MPCore on linux-2.6.34, unfortunately I have random
>> panic/segment fault with task migration. I noticed a patch set
>> [ARM11 MPCore: preemption/task migration cache coherency fixups] to fix
>> such issues in here:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-October/069851.html
>>
>> It seems there is no follow ups, is there official patch to fix such
>> issues?
>
> Let's be honest: you haven't given us a lot to go on here. Perhaps you could
> answer the following?
>
> (1) Do you experience the same issues with a more recent kernel?
> (2) If you apply the patches linked to above, does it fix your problem?
> (3) If you can reproduce on current mainline, do you have a testcase?
> (4) Does disabling CONFIG_PREEMPT make the problem disappear?
>
> That should provide us with some information about the problem.
>
Based on the limitation of CP15 of ARM11 MPCore:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0228a/index.html
The ARM11 MPCore SCU does not handle coherency consequences of CP15
cache operations like clean and invalidate. If these operations are
performed on one CPU, they do not affect the state of a cache line on a
different CPU. This can result in unexpected behavior if, say, a line
is cleaned/invalidated but a subsequent access hits a stale copy in
another CPU?s L1 through snooping the ?coherency domain?.
Kernel option CONFIG_DMA_CACHE_RWFO was introduced to fix it. details
see arch/arm/mm/cache-v6.S:
...
#ifdef CONFIG_DMA_CACHE_RWFO
ldr r2, [r0] @ read for ownership
str r2, [r0] @ write for ownership
#endif
...
I think:
1) The similar protection was not added on data cache handlers like
v6_coherent_kern_range and v6_flush_kern_cache_all.
Here I modified v6_coherent_kern_range as:
--- a/arch/arm/mm/cache-v6.S
+++ b/arch/arm/mm/cache-v6.S
@@ -170,6 +170,10 @@ ENDPROC(v6_coherent_kern_range)
ENTRY(v6_flush_kern_dcache_area)
add r1, r0, r1
1:
+#ifdef CONFIG_SMP
+ ldr r2, [r0] @ read for ownership
+ str r2, [r0] @ write for ownership
+#endif /* CONFIG_SMP */
#ifdef HARVARD_CACHE
mcr p15, 0, r0, c7, c14, 1 @ clean & invalidate D line
#else
But I have no idea on how to accomplish the v6_flush_kern_cache_all,
maybe IPI is needed?
Any opinions?
And, with this little patch above, a strange issue on my side did
*disappeared*. The issue is when enable task migration, some strange
error may occurred like Segmentation fault and:
*** glibc detected *** cat: munmap_chunk(): invalid pointer: 0xbeaa0f13 ***
[10870.314465] Unhandled fault: alignment exception (0x821) at 0xebfffee6
[10870.315347] Unhandled fault: alignment exception (0x821) at 0xebfffee6
[10870.354917] Unhandled fault: alignment exception (0x821) at 0xebfffee6
cat: invalid number 'cat'
cat: invalid number 'cat'
cat: invalid number 'cat'
cat: invalid number 'cat'
cat: \x13\x1f??\x17\x1f??: No such file or directory
cat: \x17??^[??: No such file or directory
cat: can't open ' ?*?D?_?f?o?|???????????': No such file or directory
cat: applet not found
cat: (null): Invalid argument
cat: (null): Bad address
cat: (null): Bad address
cat: \x11o??\x15o??: No such file or directory
cat: applet not found
cat: ???\x13???: No such file or directory
cat: unknown user /busybox
cat: \x17???^[???: No such file or directory
cat: applet not found
cat: ???$???: Bad address
cat: \x1a???
???: Bad address
cat: \x18\x1f??
\x1f??: Bad address
[13758.255564] Alignment trap: not handling instruction e1a00001 at
[<00033e38>]
[13758.256459] Alignment trap: not handling instruction e1a00001 at
[<00033e38>]
[13758.256522] Unhandled fault: alignment exception (0x811) at 0x0019f1aa
[13758.319272] Alignment trap: not handling instruction e1a00001 at
[<00033e38>]
[13758.340860] Unhandled fault: alignment exception (0x811) at 0x0019f1aa
[13758.361612] Unhandled fault: alignment exception (0x811) at 0x0019f1aa
--
Love each day!
--bill
next prev parent reply other threads:[~2012-05-29 5:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 9:11 Query about: ARM11 MPCore: preemption/task migration cache coherency bill4carson
2012-05-11 8:51 ` Will Deacon
2012-05-11 9:53 ` bill4carson
2012-05-29 5:28 ` bill4carson [this message]
2012-05-30 6:38 ` Will Deacon
2012-05-30 10:01 ` bill4carson
2012-05-31 3:00 ` Catalin Marinas
2012-05-31 3:11 ` bill4carson
2012-05-31 3:12 ` Catalin Marinas
2012-05-31 3:19 ` Catalin Marinas
2012-05-31 3:38 ` bill4carson
2012-05-31 3:58 ` Catalin Marinas
2012-05-31 5:06 ` bill4carson
2012-05-31 5:19 ` Catalin Marinas
2012-05-31 5:51 ` bill4carson
2012-05-31 6:56 ` Catalin Marinas
2012-05-31 7:21 ` bill4carson
2012-05-31 7:46 ` snakky.zhang at gmail.com
2012-05-31 16:04 ` Catalin Marinas
2012-06-01 1:11 ` snakky.zhang at gmail.com
2012-06-01 3:25 ` Catalin Marinas
2012-06-01 5:21 ` snakky.zhang at gmail.com
2012-06-01 1:34 ` snakky.zhang at gmail.com
2012-06-01 3:29 ` Catalin Marinas
2012-06-03 11:34 ` Russell King - ARM Linux
2012-06-04 9:20 ` snakky.zhang at gmail.com
2012-06-05 4:06 ` George G. Davis
2012-06-05 4:50 ` bill4carson
2012-06-06 6:18 ` Andrew Yan-Pai Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC45E6B.2070202@gmail.com \
--to=bill4carson@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).