Sparc slowdown - problem identified...

Thomas Moestl t.moestl at
Fri Aug 15 08:34:51 PDT 2003

On Fri, 2003/08/15 at 16:58:44 +0200, Harti Brandt wrote:
> On Fri, 15 Aug 2003, Thomas Moestl wrote:
> TM>On Fri, 2003/08/15 at 12:20:39 +0200, Harti Brandt wrote:
> TM>>
> TM>> Hi all,
> TM>>
> TM>> it seems I have identified which commit causes the slow down on some
> TM>> sparcs. The kernel from just before that commit works just fine, the
> TM>> kernel from just after it is 3x slower on my Ultra-10 (as was also
> TM>> reported by others). I have no idea why that happens. The only difference
> TM>> in the time -l report is user and system time going up by a factor of
> TM>> three and the involuntary context switches doubling.
> TM>
> TM>It seems that deferred errors (and thus the data access errors
> TM>generated due to PCI bus timeouts from non-existant devices) will
> TM>disable the instruction and data cache by resetting the corresponding
> TM>enable bits in the LSU control register, and the current code fails to
> TM>reenable them (which also requires a cache flush). A simple workaround
> TM>for now is to avoid triggering these errors, so enabling OFW_NEWPCI
> TM>should help.
> I can confirm that it helps. I assume that OFW_NEWPCI is currently there
> to allow testing and one day to throw the switch and remove the old stuff?


> Wouldn't it help to make it the default? Otherwise the testing will be
> rather limited.

I haven't made it the default because it can require configuration
changes because of the different enumeration, as detailed in the
warning notice in GENERIC and NOTES. I had hoped that making it an
option would allow people could gradually change over their
installations, so that the transition would be more painless.

I guess I should make it the default soon.

	- Thomas

Thomas Moestl <t.moestl at>
              <tmm at>
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

More information about the freebsd-sparc64 mailing list