tkevans@oss670.UUCP (Tim Evans) (03/27/91)
A photocopied "review" of ESIX System V, Rev D, which Everex
sends out in its ESIX information package to prospective buyers
contains the following statement:
"Our Acer's 32kb onboard cache must be disabled for
proper installation. The same is probably true for
other machines with caches."
Is this statement true? Does anyone have any comments about this?
Please reply via E-Mail to the address *BELOW*. Thanks.
--
INTERNET tkevans%woodb@mimsy.umd.edu
UUCP ...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
US MAIL 6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD 21235
PHONE (301) 965-3286larry@nstar.rn.com (Larry Snyder) (03/29/91)
tkevans@oss670.UUCP (Tim Evans) writes: >A photocopied "review" of ESIX System V, Rev D, which Everex >sends out in its ESIX information package to prospective buyers >contains the following statement: > "Our Acer's 32kb onboard cache must be disabled for > proper installation. The same is probably true for > other machines with caches." >Is this statement true? Does anyone have any comments about this? what good is a cache if it has to be disabled :) -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
darcy@druid.uucp (D'Arcy J.M. Cain) (03/29/91)
In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: >A photocopied "review" of ESIX System V, Rev D, which Everex > [...] > "Our Acer's 32kb onboard cache must be disabled for > proper installation. The same is probably true for > other machines with caches." > >Is this statement true? Does anyone have any comments about this? Not only is it true but it is true for one of Everex's own motherboards! I bought an Everex Step 386/25 for two reasons: I was planning on buying Everex's Esix operating system and felt that would be the safest bet. It was the fastest machine in its class at the time. It has been real annoying to have to run the system with the cache turned off. Especially annoying is when I upgraded from 4 Meg to 8. I had to buy cache memory for the upgrade to work even though I had to turn it off. I really like Esix and their support has been great but I really wish I had bought different hardware to run it on. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
john@jwt.UUCP (John Temples) (03/29/91)
In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: > "Our Acer's 32kb onboard cache must be disabled for > proper installation. The same is probably true for > other machines with caches." ESIX runs without a hitch on my cached system. This "reviewer" is rather bold to make such a statement based on a sample size of one. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
cpcahil@virtech.uucp (Conor P. Cahill) (03/29/91)
tkevans@oss670.UUCP (Tim Evans) writes: >A photocopied "review" of ESIX System V, Rev D, which Everex >sends out in its ESIX information package to prospective buyers >contains the following statement: > "Our Acer's 32kb onboard cache must be disabled for > proper installation. The same is probably true for > other machines with caches." They appear to be talking about installation time, not run time. This is usually one of the first things I do when preparing to install any OS on a system. During installation you want as few variables as possible. My "rules" for installing ISC UNIX are as follows: 1. disable caching, shadow ram, rom->ram copying, etc. 2. remove all cards from the system other than the display and disk adaptors. 3. if the display adaptor is a 16-bit adaptor, move it to an 8-bit slot, if possible. While these may not be necessary for all machines, it is easier to do this on all of them than having to reinstall because one of these problems bit you. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
root@Topsail.ORG (Chuck Murcko) (03/29/91)
In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: >A photocopied "review" of ESIX System V, Rev D, which Everex >sends out in its ESIX information package to prospective buyers >contains the following statement: > > "Our Acer's 32kb onboard cache must be disabled for > proper installation. The same is probably true for > other machines with caches." > >Is this statement true? Does anyone have any comments about this? > I use an ATEN motherboard with cache (64k) enabled, and it works just fine. I think before the net jumps on the flame bandwagon, it would be useful to say this is most likely a compatibility problem with one particular motherboard. -- Chuck Murcko The Topsail Group 538 E. Church Rd., Elkins Park, PA 19117 Internet: cmurcko@topsail.Topsail.ORG UUCP: ...!uunet!lgnp1!gvlv2!topsail!cmurcko
jon@turing.acs.virginia.edu (Jon Gefaell) (03/30/91)
In article <1991Mar29.063058.18124@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: >> "Our Acer's 32kb onboard cache must be disabled for >> proper installation. The same is probably true for >> other machines with caches." > >ESIX runs without a hitch on my cached system. This "reviewer" is >rather bold to make such a statement based on a sample size of one. >-- >John W. Temples -- john@jwt.UUCP (uunet!jwt!john) Same here, ALL ESIX revisions have run just fine on my 386/33 Everex motherboard, the AGI. This has a simple FIFO cache, not a more advanced 2 way set associative cache, or whatever like AMMA or the Intel cache controller -- ____ \ / Jon Gefaell (jon@Turing.acs.Virginia.EDU) \/ The pleasure of satisfying a savage instinct, undomesticated by the ego, is uncomparably much more intense than one of satisfying a tamed instinct. The reason is becoming the enemy that prevents us from a lot of possibilities of pleasure. S. Freud
ed@mtxinu.COM (Ed Gould) (03/30/91)
>> "Our Acer's 32kb onboard cache must be disabled for >> proper installation. The same is probably true for >> other machines with caches." >ESIX runs without a hitch on my cached system. This "reviewer" is >rather bold to make such a statement based on a sample size of one. 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. One of the things that this means is that if there are no DMA devices, then running with the cache enabled will work. If there are DMA devices, then it won't. I am currently considering an Arche 486 box, containing a DMA-snooping write-back cache, for personal use. Does anyone have any experience with Arche or their hardware? -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
jdeitch@jadpc.cts.com (Jim Deitch) (03/31/91)
In article <1991Mar29.063058.18124@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: >> "Our Acer's 32kb onboard cache must be disabled for >> proper installation. The same is probably true for >> other machines with caches." > >ESIX runs without a hitch on my cached system. This "reviewer" is >rather bold to make such a statement based on a sample size of one. >-- >John W. Temples -- john@jwt.UUCP (uunet!jwt!john) Please note that he said "proper installation". That does not mean running. I have seen a similar problem with Novell. They say to properly install the 2.x and 3.X products, you should disable caching, install the package, then reneable caching to run the product. Not sure why.. Could be the same thing for esix. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
debra@wsinis03.info.win.tue.nl (Paul De Bra) (04/02/91)
In article <1991Mar29.031716.25197@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >Not only is it true but it is true for one of Everex's own motherboards! >I bought an Everex Step 386/25 for two reasons: >... >It has been real annoying to have to run the system with the cache >turned off. Especially annoying is when I upgraded from 4 Meg to 8. I have succesfully installed (not just run) AT&T sVr3.2.1, ISC 2.0.1 and Esix rev D on the Step 386/25 with the (128k) cache ENABLED. The only possible problem I've encountered was that when reading a large number of small files form a cpio tape with the high speed everex 1/4inch driver some files were corrupt while cpio did not give an error. With the 'standard' driver (Esix or AT&T) this never happened. I believe most 386 machines follow the convention that addresses with the most significant bit on are equivalent to the same addresses with that bit turned off except for bypassing the cache. Software that follows that convention has no problem. So turn on that cache! I have encountered so many systems with problems (and read or heard about many more) that I'm convinced the few extra bucks to get the Everex Step 386/25 was a worthwile investment. Paul. (debra@win.tue.nl, debra@research.att.com)
debra@wsinis03.info.win.tue.nl (Paul De Bra) (04/02/91)
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)
james@bigtex.cactus.org (James Van Artsdalen) (04/03/91)
In <1855@svin02.info.win.tue.nl>, debra@info.win.tue.nl wrote: > I believe most 386 machines follow the convention that addresses with the > most significant bit on are equivalent to the same addresses with that bit > turned off except for bypassing the cache. Not exactly, but close. If the MSB is set, the cycle is not cached and goes out to the bus - and is not decoded as a local RAM access. That means that if you have motherboard RAM at address N, a cycle with address N gets that RAM location, but if the MSB is set, then you get the AT bus. There is at least one peripheral card that depends on this scheme to allow it to be addressed "underneath" motherboard RAM. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
pascal@CAM.ORG (Pascal Gosselin) (04/03/91)
john@jwt.UUCP (John Temples) writes: >In article <824@oss670.UUCP> tkevans@oss670.UUCP (Tim Evans) writes: >> "Our Acer's 32kb onboard cache must be disabled for >> proper installation. The same is probably true for >> other machines with caches." >ESIX runs without a hitch on my cached system. This "reviewer" is >rather bold to make such a statement based on a sample size of one. >-- >John W. Temples -- john@jwt.UUCP (uunet!jwt!john) Same here, runs fine on 486K with 128K external cache (AMI Bios, OPTI chip set) and 8megs. -- +----------------------------------------------------------------------------+ | Pascal Gosselin | Internet: P.Gosselin@CAM.ORG Applelink: CDA0585 | | Gest-Mac Inc. Apple VAR | Voice (514) 767-4444 Fax (514) 767-7337 | +----------------------------------------------------------------------------+