Date: Sun, 4 Apr 2010 14:57:46 +0000 (UTC) From: Marius Strobl <marius@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/sparc64/include dcr.h src/sys/sparc64/sparc64 cheetah.c Message-ID: <201004041458.o34Ew8mR058785@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
marius 2010-04-04 14:57:46 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_8)
sys/sparc64/include dcr.h
sys/sparc64/sparc64 cheetah.c
Log:
SVN rev 206162 on 2010-04-04 14:57:46Z by marius
MFC: r205269
o Add support for UltraSparc-IV+:
- Swap the configuration of the first and second large dTLB as with
US-IV+ these can only hold entries of certain page sizes each, which
we happened to chose the non-working way around.
- Additionally ensure that the large iTLB is set up to hold 8k pages
(currently this happens to be a NOP though).
- Add a workaround for US-IV+ erratum #2.
- Turn off dTLB parity error reporting as otherwise we get seemingly
false positives when copying in the user window by simulating a
fill trap on return to usermode. Given that these parity errors can
be avoided by disabling multi issue mode and the problem could be
reproduced with a second machine this appears to be a silicon bug of
some sort.
- Add a membar #Sync also before the stores to ASI_DCACHE_TAG. While
at it, turn of interrupts across the whole cheetah_cache_flush() for
simplicity instead of around every flush. This should have next to no
impact as for cheetah-class machines we typically only need to flush
the caches a few times during boot when recovering from peeking/poking
non-existent PCI devices, if at all.
- Just use KERNBASE for FLUSH as we also do elsewhere as the US-IV+
documentation doesn't seem to mention that these CPUs also ignore the
address like previous cheetah-class CPUs do. Again the code changing
LSU_IC is executed seldom enough that the negligible optimization of
using %g0 instead should have no real impact.
With these changes FreeBSD runs stable on V890 equipped with US-IV+
and -j128 buildworlds in a loop for days are no problem. Unfortunately,
the performance isn't were it should be as a buildworld on a 4x1.5GHz
US-IV+ V890 takes nearly 3h while on a V440 with (theoretically) less
powerfull 4x1.5GHz US-IIIi it takes just over 1h. It's unclear whether
this is related to the supposed silicon bug mentioned above or due to
another issue. The documentation (which contains a sever bug in the
description of the bits added to the context registers though) at least
doesn't mention any requirements for changes in the CPU handling besides
those implemented and the cache as well as the TLB configurations and
handling look fine.
o Re-arrange cheetah_init() so it's easier to add support for SPARC64
V up to VIIIfx CPUs, which only require parts of this initialization.
Committed from: EH2010
Revision Changes Path
1.1.4.2 +4 -0 src/sys/sparc64/include/dcr.h
1.10.2.3 +73 -34 src/sys/sparc64/sparc64/cheetah.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004041458.o34Ew8mR058785>