On Sun, Oct 25, 2009 at 02:37:40PM -0700, Marcel Moolenaar wrote: > > On Oct 25, 2009, at 1:25 PM, Marius Strobl wrote: > > > >Do you have a simple test case demonstrating the need for > >I-cache synchronisation? > > I typically use GDB. If breakpoints aren't being hit or > next isn't behaving correctly, you typically have an > I-cache problem. If you get to run GDB, you probably > already know whether it's needed, because processes > tend to die with random signals at startup when the > architecture needs explicit I-cache coherency logic > and the kernel doesn't have it. A special case I would > say is executing from a memory disk. The I/O path > contains bcopy() operations, which dirty the D-cache > and trigger I-cache coherency bugs pretty well. > > I didn't have issues with that on my Netra, so I didn't > implement pmap_sync_icache for sparc64. This is not to > say that it's absolutely not needed, just that GDB didn't > expose problems. If sparc64 has some of the same kluges > powerpc had, then I-cache coherency is handled in some > other (most likely a sub-optimal) way. >
The cheetah-class CPUs, i.e. USIII and later, take care of I$ coherency themselves, unlike the spitfire ones (see also cheetah_icache_page_inval() vs. spitfire_icache_page_inval()). So your Netra 20/T4 shouldn't exhibit such problems while spitfire-based machines likely require the I$ to be flushed. I currently can't think of any existing code which would ensure I$ consistency after the writes have been performed, not even as a side-effect. The proper solution probalby is to make pmap_sync_icache() a wrapper around icache_page_inval(). Marius _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
