Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!uunet!mcsun!sunic!isgate!veda.is!adam From: adam@veda.is (Adam David) Newsgroups: comp.os.386bsd.bugs Subject: Re: This is a strange one! Message-ID: <C4354r.Mw9@veda.is> Date: 18 Mar 93 12:53:15 GMT References: <1993Mar16.102750@axion.bt.co.uk> <C40400.9qv@veda.is> <1993Mar17.184040.2765@fcom.cc.utah.edu> Organization: Veda Systems, Iceland Lines: 38 terry@cs.weber.edu (A Wizard of Earth C) writes: >The *ONLY* place I have been able to duplicate this is with a system with >cache (with the cache turned on) *AND* a bus-mastering disk controller that >writes directly to memory (ie: controller initiated DMA). aha-1542B, is that a bus master? >The processor goes to read the contents of the file system buffer, and >the hardware *INCORRECTLY REPORTS A CACHE HIT*! Thus the data read is >not the updated data from main memory, but the previous contents of the >cache which believes it holds correct data. Ouch! >The *ONLY* soloutions to this problem are to (1) disable the cache, (2) >set jumpers so cache invalidation occurs correctly, (3) use a stupid >controller that requires the main CPU to do the data transfers, or (4) >replace the faulty motherboard. 1) is not an option, but useful for testing purposes. 2) no such jumper :-( 3) Which SCSI boards do CPU-initiated DMA ? 4) I'll probably end up using this motherboard for Linux and get a more reliable one for 386BSD. Anyone know of a good board with a 486dx2-100 or a 486dx3-99 ? >People, quit blaming the FS buffer cache, which is easily regression >tested and proven stable, for problems resulting from inferior or >incorrectly configured hardware. Concurred, this one should definitely be in the FAQ in wording as clear as the previous article, it seems to be a common enough problem and easily enough misunderstood if not worded carefully (dual usage of the word "cache"). Thanks Terry, for doing the subject justice. -- Adam David (adam@veda.is)