*BSD News Article 12942


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)