linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).