Date: Fri, 15 Aug 2003 16:34:04 +0200 From: Thomas Moestl <t.moestl@tu-bs.de> To: Tillman <tillman@seekingfire.com> Cc: sparc64@freebsd.org Subject: Re: Sparc slowdown - problem identified... Message-ID: <20030815143404.GB701@crow.dom2ip.de> In-Reply-To: <20030815080055.O22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/
<tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815143404.GB701>