From owner-svn-src-all@FreeBSD.ORG Mon Oct 26 20:11:18 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8627A106566B; Mon, 26 Oct 2009 20:11:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id E609F8FC1D; Mon, 26 Oct 2009 20:11:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n9QKBGY5095749; Mon, 26 Oct 2009 21:11:16 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n9QKBGAO095748; Mon, 26 Oct 2009 21:11:16 +0100 (CET) (envelope-from marius) Date: Mon, 26 Oct 2009 21:11:16 +0100 From: Marius Strobl To: Marcel Moolenaar Message-ID: <20091026201116.GS27159@alchemy.franken.de> References: <200910211838.n9LIc2wp007206@svn.freebsd.org> <20091025202541.GC94979@alchemy.franken.de> <36313C38-9B60-4BF3-885C-5BAAA915DCFE@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36313C38-9B60-4BF3-885C-5BAAA915DCFE@mac.com> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r198341 - in head/sys: amd64/amd64 arm/arm arm/mv i386/i386 i386/xen ia64/ia64 kern mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/sparc64 sun4v/sun4v vm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:11:18 -0000 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