From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 06:50:28 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AE8837B404 for ; Fri, 15 Aug 2003 06:50:28 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D7FC43FDD for ; Fri, 15 Aug 2003 06:50:26 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 17031 invoked by uid 65534); 15 Aug 2003 13:50:24 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp025) with SMTP; 15 Aug 2003 15:50:24 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19neyR-0000cm-Kd; Fri, 15 Aug 2003 15:50:35 +0200 Date: Fri, 15 Aug 2003 15:50:35 +0200 From: Thomas Moestl To: Harti Brandt Message-ID: <20030815135034.GA701@crow.dom2ip.de> Mail-Followup-To: Harti Brandt , sparc64@freebsd.org, jmg@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815121010.I97608@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: jmg@freebsd.org cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 13:50:28 -0000 On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote: > > Hi all, > > it seems I have identified which commit causes the slow down on some > sparcs. The kernel from just before that commit works just fine, the > kernel from just after it is 3x slower on my Ultra-10 (as was also > reported by others). I have no idea why that happens. The only difference > in the time -l report is user and system time going up by a factor of > three and the involuntary context switches doubling. It seems that deferred errors (and thus the data access errors generated due to PCI bus timeouts from non-existant devices) will disable the instruction and data cache by resetting the corresponding enable bits in the LSU control register, and the current code fails to reenable them (which also requires a cache flush). A simple workaround for now is to avoid triggering these errors, so enabling OFW_NEWPCI should help. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C