From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 07:33:57 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 6160437B401 for ; Fri, 15 Aug 2003 07:33:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A35343FBF for ; Fri, 15 Aug 2003 07:33:55 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 6538 invoked by uid 65534); 15 Aug 2003 14:33:53 -0000 Received: from p508E5396.dip.t-dialin.net (EHLO galatea.local) (80.142.83.150) by mail.gmx.net (mp003) with SMTP; 15 Aug 2003 16:33:53 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19nfeW-0000js-FO; Fri, 15 Aug 2003 16:34:04 +0200 Date: Fri, 15 Aug 2003 16:34:04 +0200 From: Thomas Moestl To: Tillman Message-ID: <20030815143404.GB701@crow.dom2ip.de> Mail-Followup-To: Tillman , sparc64@freebsd.org, jmg@freebsd.org References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030815080055.O22214@seekingfire.com> 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 14:33:57 -0000 On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote: > On Fri, Aug 15, 2003 at 03:50:35PM +0200, Thomas Moestl wrote: > > 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. > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it > now and go through any needed reconfiguration will I be saving myself > time in the future? Yes. > The notes for OFW_NEWPCI say: > > # New OpenFirmware PCI framework. This fixes a number of interrupt- > # routing problems and changes the device enumeration to be hopefully > # closer to Solaris. Be aware that, because of the latter, enabling or > # disabling this option may require reconfiguration, and can even > # cause the machine to not boot without manual intervention before the > # fstab is adjusted. > > What sort of changes are likely to occur that would affect fstab? The > box is remote, so I can fix most things via a serial console as long as > it'll boot :-) If you've got multiple SCSI or ATA controllers installed, the order in which they are recognized might change, which affects the enumeration of the devices attached to them. It should be no problem to boot into single user and request a mountroot prompt ('boot -as' from the loader), then identify the new disk enumeration, mount the root file system from the prompt and finally adjust the fstab in single user mode as required. - 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