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