*BSD News Article 13046


Return to BSD News archive

Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: This is a strange one!
Message-ID: <1993Mar20.223305.1413@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <C40400.9qv@veda.is> <1993Mar17.184040.2765@fcom.cc.utah.edu> <C4354r.Mw9@veda.is>
Date: Sat, 20 Mar 93 22:33:05 GMT
Lines: 90

In article <C4354r.Mw9@veda.is> adam@veda.is (Adam David) writes:
>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).

I need to corrrect this; it was pointed out to me that the same thing could
happen on an L2-write back cache.  I knew that, but didn't realize my
original posting implied that only cached areas written to by the controller
would not reflect the contents of real memory.  It is also possible for the
contents of real memory to not reflect the contents of a [supposedly]
updated area of memory where the changes only exist in the cache.  This
probably should have read:

	...a bus-mastering disk controller that performs controller
	initiated DMA (ie: reads/writes memory directly).

One suggestion that has been made by Leonard N. Zubkoff (I've been exchanging
email with 3 people on the subject... apparently a hot topic!) was that the
pages for the buffers be invalidated (WBINVD).  He wen on to say that this
is probably too drastic a soloution.  Another was referencing cache lines
for memory causing the write-back to occur; this was worse, in my mind,
because it would imply causing the cache to empty by forcing other data
into it... also requiring you know what's in the cache in the first place.
The best soloution by far would be to turn off the cacheable bit in the
page map for buffer cache pages; Leonard points out that this assumes an L2
cache will honor that, meaning that some motherboards that are badly
designed may never correctly support DMA.

>aha-1542B, is that a bus master?

Generally speaking, anything that does board initiated DMA is bus mastering
(since it requires a bus grant to do the DMA).  Almost all (if not all!)
SCSI drivers supported under Julian's driver ar bus mastering, as are at
least 2 of the ethernet drivers floating around out there (from memory --
I don't have names for them for worried people).

>>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!

Worse, on a write-back of a memory region that will not be read until
updated, data read by the controller *may* be overwritten in the L2 scenerio
by data already in the cache scheduled for write-back but before write-back
has actually ocurred.

>>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 ?

If you have to set up or identify a DMA channel, it's "bus mastering".

>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 ?

If Leonard's suggestion works (and someone implements it), this shouldn't
be a problem... the board should be fine for 386BSD.

The other problem which should probably be addressed at the same time is
the 10-bits of DMA on ISA boards that prevents the SCSI drivers from working
when you have more than 16M of memory.  I've hacked a workaround for this
particular problem, but am far from happy with it; it was more in the
neighborhood of a feasability experiment.

Someone probably needs to adopt Julian's drivers.  I don't know if the
cachable bit is dealt with in the 0.2 VM system or whether we need to
do something else about it.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------