Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site x.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!hplabs!pesnta!amd!vecpyr!lll-lcc!lll-crg!seismo!harvard!think!mit-eddie!cybvax0!frog!x!rfm
From: rfm@x.UUCP (Bob Mabee)
Newsgroups: net.arch
Subject: Re: 386 info
Message-ID: <830@x.UUCP>
Date: Tue, 5-Nov-85 22:06:23 EST
Article-I.D.: x.830
Posted: Tue Nov  5 22:06:23 1985
Date-Received: Mon, 11-Nov-85 06:11:28 EST
References: <965@mcnc.mcnc.UUCP>
Reply-To: rfm@x.UUCP (PUT YOUR NAME HERE)
Distribution: net
Organization: Charles River Data Systems, Framingham MA
Lines: 15

In article <965@mcnc.mcnc.UUCP> jnw@mcnc.UUCP (John White) writes:
(summarizing Intel release on the new 386)
>First, if all 32 entries in the cache
>are used, then one must be freed up. As the access and dirty bits may have
>been changed, the entry must be written back to the page table.

This is a bug (or misquoted).  The accessed and dirty bits have to be written
back to memory immediately they are set, using a bus-lock read-alter-rewrite
cycle to set just the bit of interest.  Otherwise the chip can not be used
(reasonably) in a multi-cpu system.  Also, even with a single processor there
would have to be a way to force the dirty bits to get written out before the
system can look for a good page to evict.
-- 
				Bob Mabee @ Charles River Data Systems
				decvax!frog!rfm