shared memory problem on ARM v5TE using threads

[Ronen Shitrit]

There is another possible solution we are looking into:
1) Force all NC writes to go through L2: 
If there is a hit in the L2, the write will update the L2 together with the DRAM.
If there is a miss, the write will continue to the DRAM only.
2) Force all NC reads to wait till L2 write buffer is drained, to avoid any racing with above...
3) Set L2 in WT mode.

I still can't determine if this solution is valid from HW point of view, but I will really appreciate any comment on this.
Any thoughts? Any pitfalls this solution is missing?

Thanks

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] 
Sent: Sunday, December 13, 2009 2:06 PM
To: Ronen Shitrit
Cc: hs at denx.de; saeed bishara; linux-arm-kernel at lists.infradead.org; Nicolas Pitre
Subject: Re: shared memory problem on ARM v5TE using threads

On Sun, Dec 13, 2009 at 12:00:33PM +0000, Russell King - ARM Linux wrote:
> I'm afraid to say that the only solution I can see to this problem is to
> disable the L2 cache outright on these CPUs - the choice seems to be
> between correct system behaviour and lower performance, or performance
> but buggy system behaviour in certain cases leading to data corruption.

BTW, if no one can come up with a solution for this, we need to consider
making the kernel by default disable L2 cache on Feroceon, and display a
warning message if L2 is to be enabled.

We really can not have a known data corrupting issue like this exist
silently in the system - it's not fair for users nor developers to waste
time trying to work out why their data is being corrupted.