fmcgee@cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~L25~6326~) (07/22/89)
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
jr@frog.UUCP (John Richardson) (07/25/89)
In article <2944@cuuxb.ATT.COM>, fmcgee@cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~L25~6326~) writes: > In article <7831@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > > About cache problems and shared memory boards.... > > 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. > The INTEL 80385 cache controlller does not know about what should be or what should not be cached. It has an input pin called NC for NO CACHE that is valid for the current cycle to the cache controller chip. It is up to external logic to drive this pin. A recommendataion has been to use A31. Most motherboards (all?) will always decode and not cache 640K to 1MEG. The A31 convention will work for UNIX, but OS/2 will be a problem. Even though you can set A31 without paging by using the 80386 segment base extention byte (the highest of the 8 byte descriptor), I do not remember from the last OS/2 driver that I wrote if the current non-386 OS/2 allows you to set this byte. (Short of reading the GDT register to find out where it is, and find your selector in it and set it yourself!) SIGH! (there are undocumented OS/2 DEVHLP's that allow you to permenantly allocate GDT entrys for your driver) JR
kdg@nirvo.uucp (Kurt Gollhardt) (07/27/89)
In article <2944@cuuxb.ATT.COM> fmcgee@cuuxb.UUCP (Frank W. McGee) writes: >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. The 82385 has a (single) input pin which says "don't cache this address". It is up to external circuitry - read: motherboard designer - to decode the addresses which are not to be cached. Unfortunately, this is not usually done in a flexible way. -- ============== ============== # Kurt Gollhardt Nirvonics, Inc. -- Plainfield, NJ # # ...!rutgers!nirvo!kdg Software Design and Consulting # ============== ==============