Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!svin02!wsinis03!debra
From: debra@wsinis03.info.win.tue.nl (Paul De Bra)
Newsgroups: comp.unix.sysv386
Subject: Re: ESIX and Caching Motherboards
Message-ID: <1856@svin02.info.win.tue.nl>
Date: 2 Apr 91 11:05:07 GMT
References: <824@oss670.UUCP> <1991Mar29.063058.18124@jwt.UUCP> <1991Mar29.184802.17438@mtxinu.COM>
Sender: news@svin02.info.win.tue.nl
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, The Netherlands
Lines: 21

In article <1991Mar29.184802.17438@mtxinu.COM> ed@mtxinu.COM (Ed Gould) writes:
>This may not be based on a sample at all, but on analysis.  The
>reason I can imagine for requiring the cache to be disabled is
>this:  It's a write-back cache that doesn't snoop on DMA, and
>there's no software support to maintain cache consistency.

Two years ago the cache/no cache issue was debated at length in this
newsgroup (actually, comp.unix.i386 at that time). If I'm not mistaken the
conclusion was that the so called 'A31 convention' (using the msg of the
address bus) for bypassing the cache provided the hardware hook to make
software support for maintaining cache consistency possible. I think it
will be a long while before memories will become too large to be addressable
with only 31 bits.

Many flavors of Unix (sVr3.1 and 3.2 and 4.0) run flawlessly on different
386 motherboards with cache enabled. I think the adds for 'cache snooping'
motherboards are pure marketing hype. Or is there more to it than we currently
know? 

Paul.
(debra@win.tue.nl, debra@research.att.com)