Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcsvax!ucsdhub!cuuxun!cuuxb!fmcgee
From: fmcgee@cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~L25~6326~)
Newsgroups: comp.unix.i386,comp.sys.att
Subject: Re: Cache disabling -- why a big deal?
Summary: sometimes it's a big deal
Keywords: cache 80386 dual ported RAM
Message-ID: <2944@cuuxb.ATT.COM>
Date: 21 Jul 89 17:13:06 GMT
Expires: 7 Aug 89 23:00:00 GMT
References: <40@oink.UUCP> <7831@hoptoad.uucp>
Reply-To: fmcgee@cuuxb.UUCP (Frank W. McGee)
Followup-To: comp.sys.att
Distribution: na
Organization: AT&T, Data Systems Group, Lisle, IL
Lines: 26

In article <7831@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>Did Intel really forget to put a "don't cache" bit in the MMU page
>table entries?  Did they forget to bring this pin out to the rest of
>the hardware?  Or did the entire set of people designing 386
>motherboards ignore this pin?  Why are people in virtual memory Unix
>systems having to muck around swapping PALs to disable cache access for
>I/O addresses?  Autoconfig does this in software in my Sun system -- it
>sets don't-cache when mapping in I/O devices for the drivers.
>I realize that under MSDOS some sort of hardware hack would be necessary
>(since it doesn't use page tables), but under Unix you ought to be covered.
>John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com

I'm not an expert on the 82385, but I believe that it may be the case
that it doesn't know that some areas of memory shouldn't be cached.  On
the 6386/25 and 6386/33 (machines that AT&T announced Monday), the
cache is implemented in discrete logic so that it only caches address
space that is really occupied by RAM.  Basically, it doesn't cache any
address space that isn't in a 32-bit slot (ie, it's in an AT or XT
expansion slot, and is memory on some sort of expansion card).  That
way you don't have to re-write your drivers if your card has dual
ported RAM.

-- 
Frank McGee, AT&T
Tier 3 Indirect Channel Sales Support
attmail!fmcgee