Sparc slowdown - problem identified...

[Tillman]

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