Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!snorkelwacker!apple!olivea!orc!bbn.com!nic!hri!sparc2!limey
From: limey@sparc2.hri.com (Craig Hughes)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <1990Aug29.150017@sparc2.hri.com>
Date: 29 Aug 90 23:00:17 GMT
References: <1990Aug3.204358.330@portia.Stanford.EDU> <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> <2421@crdos1.crd.ge.COM> <1990Aug18.210132.25203@sco.COM> <2434@crdos1.crd.ge.COM> <6797.26d6edce@vax1.tcd.ie> <41161@mips.mip
Sender: news@hri.com
Reply-To: limey@hri.com
Organization: Horizon Research, Inc.
Lines: 20

In the interest of keeping the machine up, even with a potentially fatal
problem, how about having the hardware notify the OS (through some kind
of exception) that there is a problem with a certain area of memory? The
O/S could then dynamically remove that portion of physical
memory from it's virtual map after copying the data to a new page, 
log the error, and continue processing. The corrupted data isn't fixed,
but at least the machine is still running - and that can be imporant
sometimes. (reminds me of a military computer I've seen with a big
'combat mode' button on the front - apparently when pressed all exceptions
would be ignored.......)
--
------------------------------------------------------------------------
---------
Craig S. Hughes				UUCP: ...bbn!hri.com!limey
Horizon Research, Inc.			INET: limey@hri.com
1432 Main Street
Waltham, MA 02154			
			<- ------------- ->
------------------------------------------------------------------------
---------