ricks@hawk.isc-br.com (Rick Schaeffer) (03/11/90)
I have an Amiga 2500/30 and customarily run SetCPU (1.5) in my startup sequence to enable Burst mode and Data Cache. I have read some warnings about things that can get messed up when using Data Cache but have not until now experienced any problems. 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. Are there any other specific things that shouldn't be done with data cache (and/or burst mode) enabled? Should this be considered a bug in Blink? I understand that it is probably DMA that screws up data cache so I should mention that I am using a Microbotics Hardframe disk controller. Would any other DMA controller have similar problems?
daveh@cbmvax.commodore.com (Dave Haynie) (03/13/90)
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
steveb@cbmvax.commodore.com (Steve Beats) (03/14/90)
In article <10121@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >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. Ahem, actually Dave, the A2091 does flush the data and instruction caches if an 030 is present in the system. It`s a bit drastic but there is no system supported way of finding out exactly what memory areas are cached, so the whole lot has to go. I don`t think there`s any way of determining what`s been cached, even in hardware, is there ? Steve -- _________________ / __ __ \ Commodore/Amiga Inc. | This space left ( (__' |__) ) Email: cbmvax!steveb | intentionally ( ,__)teve |__)eats ) BIX: sbeats | blank! \_________________/ PHONE: (215) 431-9100 | 01144 482 824141 (UK phone)
daveh@cbmvax.commodore.com (Dave Haynie) (03/16/90)
In article <10158@cbmvax.commodore.com> steveb@cbmvax (Steve Beats) writes: >In article <10121@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >>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. >Ahem, actually Dave, the A2091 does flush the data and instruction caches >if an 030 is present in the system. Cool! I remember the night you hacked that in there (write allocate bit and all), but I didn't know if that actually made it to production ROMs or not. That's the best thing anyone could have done under 1.3 to support data caching, but won't help on a machine with external cache or a 68040. >It`s a bit drastic but there is no system supported way of finding out >exactly what memory areas are cached, so the whole lot has to go. I don`t >think there`s any way of determining what`s been cached, even in hardware, >is there ? Not from your point of view. Caches always know what they have cached, but don't always let you know. You wouldn't really want to know, anyway. You only know what you've modified, so the best thing the OS could do would be to let you say something like: ClearCache(buffer,length); Or in your language, move.l buffer,d0 move.l length,a0 CALLSYS ClearCache Anyway, some cache configurations allow line or block flushes. Others may actually snoop the bus in hardware in one of several ways and make the flush unecessary. You shouldn't ever have to worry about the implementation details of the cache consistency mechanism. I guess the only other extra information a cache manager would find useful at some point would be a tag passed to the the ClearCache() call that indicates where the DMA device was. It's not always certain that CPU bus DMA vs. expansion bus DMA will have the same effect on the host CPU's cache. Anyway, thanks for the news on the 2091 driver. I've been running with data cache on. > Steve -- 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
markv@kuhub.cc.ukans.edu (03/29/90)
> That's the best thing anyone could have done under 1.3 to support data > caching, but won't help on a machine with external cache or a 68040. But it wont be a problem on a 68040. > Anyway, some cache configurations allow line or block flushes. Others may > actually snoop the bus in hardware in one of several ways and make the > flush unecessary. The 68040 does this both ways. It snoops the bus for accesses to memory it has cached. If it is a write access, it turns around and marks those cache entries invalid, it senses a read access, it inhibits the read cycle and takes it over, putting out the cached value for whatever is trying to read it (or flushing the entries). Of course this only works on machines that fully implement the 68040s cache and bus control lines. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~