Date: Fri, 15 Aug 2003 08:00:56 -0600 From: Tillman <tillman@seekingfire.com> To: sparc64@freebsd.org Cc: jmg@freebsd.org Subject: Re: Sparc slowdown - problem identified... Message-ID: <20030815080055.O22214@seekingfire.com> In-Reply-To: <20030815135034.GA701@crow.dom2ip.de>; from t.moestl@tu-bs.de on Fri, Aug 15, 2003 at 03:50:35PM %2B0200 References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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 :-) Thanks! -T -- The supreme irony of life is that hardly anyone gets out alive. - Robert Heinlein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815080055.O22214>