Fix a major sun4m stability problem showed up as random segv's and other

failures in innocent programs.  Typically something like a make build
of libc or something executing a large number of shell commands would
fail, dumping core in sh or random faults in as or cc*.

According to Chris Torek, the problem is that he make the destination
pages for zero and copy be non-cached to prevent wiping otherwise
relevant stuff from the cache.

On systems with a L2 cache like the SS10 modules with cache, setting
the pages as non-cacheable inhibits updating the chache, and also
disable PA chache snooping, doesn't do anything about possible dirty
lines in the L2 cache, which may eventually get flushed and corrupt the
nice new page.

It's not clear that he's got the failure mode 100% correct, but making
the pages cacheable does seem to avoid the symptoms and testing the
e-cache flush hypothesis is difficult.

Aaron Brown proposed a fix that was conditional on mmutype, and netbsd-current
has it conditional on a cpu.quirk, at the moment this is unconditional, the
performance hit is arguable...

0 files changed, 0 insertions, 0 deletions