tony@artecon.UUCP (03/02/87)
Ok, now I'm getting track #40 trashed. What I have running is: memclock ( should not be a problem ) lav ( another shouldnt be a problem, however, it needed a larger stack than the default) Matt's shell (Latest version, it reports V2.03 22Oct86, but Matt said something about forgetting to change it to 2.04?) ray (as in DBW_render, running in its own window) The symptom is that I run 'ray' in its own window, and let the shell remain idle, several hours later, a requestor reports a read/write error, and diskdoctor reports a trashed track #40. I am running with 1.2 workbench with stack set to 20000. I remember that somepeople have had this problem with the 'M' versions of the shell, but I am not using one of the 'M' versions, just the normal version. Any ideas or suggestions?? Also, I am having one other interesting interaction between the shell and AmigaMon. If run mon then check the open files, no problem, then I get back to the shell, do a dev on the disk, then run mon again, do an open files check, then it gurus. (I think the number was 000...003.0000A17 (unfortunately, I left the number at home.) -- **************** Insert 'Standard' Disclaimer here: OOP ACK! ***************** * Tony Parkhurst -- {hplabs|sdcsvax|ncr-sd|hpfcla|ihnp4}!hp-sdd!artecon!adp * * -OR- hp-sdd!artecon!adp@nosc.ARPA * *******************************************************************************
dillon@CORY.BERKELEY.EDU.UUCP (03/04/87)
The problem seems to be caused by the Blitter Bug, as far as I can figure out. At least, it seems to crop up whenever I do disk I/O simultaniously with a DEMO program which does a lot-of-little-blits. (Question to C-A: Is it possible to look at the count or address register to tell if the blit has started or not?) It doesn't seem to be related to the M versions of my shell by Steve Drew.... it has happened to me with a normal shell. I'm currently doing tests from a bare CLI (but I think it's a problem with the blitter). -Matt