]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC: r205269
authormarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 4 Apr 2010 14:57:46 +0000 (14:57 +0000)
committermarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 4 Apr 2010 14:57:46 +0000 (14:57 +0000)
commit45a38da535487d42529fa4237ac31ca2906884e3
tree518afbcb03a76eccb93f87f7272b226e6973c652
parentc95c961e80a8828bd35cfc4b64d61f6a4c5a7559
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

git-svn-id: svn://svn.freebsd.org/base/stable/8@206162 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/sparc64/include/dcr.h
sys/sparc64/sparc64/cheetah.c