Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 2630 Data Cache
Message-ID: <10121@cbmvax.commodore.com>
Date: 12 Mar 90 20:35:06 GMT
References: <345@hawk.isc-br.com>
Reply-To: daveh@cbmvax (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 48

In article <345@hawk.isc-br.com> ricks@hawk.isc-br.com (Rick Schaeffer) writes:

>In trying to get NetHack3.0 up on my machine I have successfully gotten
>everything to compile (using Lattice 5.04) but couldn't get the link
>to run.  It would guru every time in the middle of running blink and
>would force my hard disk to validate on the subsequent re-boot.  One time
>the disk validation was unable to complete and my disk was lost (thank
>goodness, I had a backup).  Anyway...to make a long story short, it 
>occured to me to try turning off the 68030's burst and data cache modes
>and then the link ran just fine!  So...I've got a reproducible case
>where data cache gets things messed up and I'm curious to know about
>any other things to watch out for.  

It's actually impossible to tell just from the description what the trouble
is, though it certainly sounds like a cache consistency problem.  There
are two problems that you can run into with the caches.  The more trivial 
of the two is self-modifying code, or similar things, in which code in the
cache is changed as if it were data.  The I-Cache doesn't flush data 
operations, but data operations are required to modify anything.  So if
you modify code that's in the cache, you update only the RAM version -- 
the cached version runs unmodified.  I hope BLINK doesn't do anything like
this, self-modifying code is almost exclusively found in older video games.

The other problem is disk buffering with DMA.  If a program mucks with a
small buffer, some of that buffer gets cached.  If it then runs a DMA load
into that buffer very without the cache somehow getting flushed, the
next time it accesses the buffer, the old data may still be in the cache.
As few as 16 data operations can completely overwrite the data cache, but
it is in theory possible to get stale data with DMA.  It doesn't depend
on the DMA device itself, but it depends alot on the software at the
driver and filesystem levels.

>Should this be considered a bug in Blink?  

Flushing of the cache to support DMA belongs in the device driver.  If
that's what's tripping up Blink, its not a Blink problem.  Under 1.3,
there's no standard way of doing cache flush, so most device drivers
(including those from Commodore) don't do this.  It's hard to imagine
what Blink could do to cause this, though -- it's impossible to do any
real disk I/O without swapping tasks, and anything fetched from a 
software disk cache would involve the CPU and thus update the cache.
Sounds like someone needs to take a look at this situation.


-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough