From: David Miller <da...@davemloft.net> Date: Tue, 09 Jun 2015 00:34:14 -0700 (PDT)
> Your test is faulty. > > You cannot use ASI_BLK_P loads or stores without appropriate memory > barriers around them. Um, but my test isn't testing what is being stored to memory at all. It is storing to memory and **never loading from the memory after**. Why would writing FROM fp registers TO memory corrupt the *registers* due to a missing memory barrier? If problem 1 is due to a missing membar somewhere, I think it's surely gotta be the kernel that's missing it, not my test code. No? > FWIW, you're probably hitting the bug fixed by the following commit in > glibc: > > commit 834caf06f33d79be54cff63c274fba2845513593 > Author: Jose E. Marchesi <jose.march...@oracle.com> > Date: Sat May 17 11:20:27 2014 -0700 > > Fix sparc memcpy data corruption when using niagara2 optimized routines. > > * sysdeps/sparc/sparc64/multiarch/memcpy-niagara2.S: Add missing > membar to avoid block loads/stores to overlap previous stores. > Debian glibc has multiarch support disabled (done a couple years ago to try to workaround the unreliability, not entirely successfully..), so it's not using that routine you mention. It's using sysdeps/sparc/sparc32/sparcv9/memcpy.S which points to sysdeps/sparc/sparc64/memcpy.S [sorry for the duplicate post -- didn't realize vger.kernel.org doesn't accept emails sent by the android gmail client] -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ecf5d654-b024-4286-a22f-bf6cdf437...@google.com
