From owner-svn-src-all@FreeBSD.ORG Sun Oct 25 21:37:56 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 564D91065670; Sun, 25 Oct 2009 21:37:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 3E2B98FC08; Sun, 25 Oct 2009 21:37:56 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KS300F74AQV8N10@asmtp024.mac.com>; Sun, 25 Oct 2009 14:37:55 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20091025202541.GC94979@alchemy.franken.de> Date: Sun, 25 Oct 2009 14:37:40 -0700 Message-id: <36313C38-9B60-4BF3-885C-5BAAA915DCFE@mac.com> References: <200910211838.n9LIc2wp007206@svn.freebsd.org> <20091025202541.GC94979@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.1076) 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: Sun, 25 Oct 2009 21:37:56 -0000 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. FYI, -- Marcel Moolenaar xcllnt@mac.com