From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Eckhardt <davide+p9@cs.cmu.edu>
To: 9fans@9fans.net
In-Reply-To: <8f6ef34730ac116e3d6a1d45ac557816@ladd.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <31832.1266781587.1@lunacy.ugrad.cs.cmu.edu>
Date: Sun, 21 Feb 2010 14:46:27 -0500
Message-ID: <31833.1266781587@lunacy.ugrad.cs.cmu.edu>
Subject: Re: [9fans] pineview atom
Topicbox-Message-UUID: d7bb9968-ead5-11e9-9d60-3106f5b1d025

>> "Back in the old days", a lot of VAX-11/750's running BSD Unix
>> crashed because of parity errors in their TLB's.  750's running
>> VMS "didn't have this problem", because VMS would silently work
>> around it; BSD grew that code--see, for example, <229@astrovax.UUCP>.
>> Then bits could flip all the time with nobody noticing!

> nobody noticed, or the os reloaded the tlb?

This was back in the days when TLB's loaded themselves.  I think
the work-around code as to flush the entry.

I mentioned the example because:

* Bits were flipping pretty often.  I think we got 10-ish events
per day.

* If there hadn't been parity protection, the result would have
been occasional unrepeatable weird crashes and data corruption.
That would have been really painful.  This isn't the same as the
general RAM case, because there aren't quiet backwaters of a
TLB which can go bad with no effect.

* Because VMS silently worked around the error and BSD didn't, for
a while the issue was a perplexing "Unix problem":  BSD ran pretty
well on older 750's and much less well on newer ones; VMS ran fine
on both.  In actuality the problem was quality control inside DEC,
but the combination of parity and restarting the operation enabled
successful computation on somewhat sketchy hardware.

Dave Eckhardt