Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!oliveb!amiga!neil
From: neil@amiga.UUCP (Neil Katin)
Newsgroups: comp.sys.amiga
Subject: Re: The Delay(0) problem is really in the timer.device
Message-ID: <2086@amiga.UUCP>
Date: 10 May 88 17:27:51 GMT
References: <409@ritcv.UUCP> <2193@antique.UUCP> <2093@munnari.oz> <2347@louie.udel.EDU> <5877@well.UUCP> <3741@cbmvax.UUCP> <4319@watcgl.waterloo.edu>
Reply-To: neil@spam.UUCP (Neil Katin)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 28

In article <4319@watcgl.waterloo.edu> rmariani@watmum.waterloo.edu (Rico Mariani) writes:
>The problem is definately in the timer.device.  Warrior Cycles doesn't
>use Delay() for its timing at all and was bitten by a Delay(0) type bug
>when zero delays were requested from the timer.device directly.  There
>is definately something rotten in timer.device but it is very subtle. 
>It didn't manifest itself at all on my system with a hard drive
>installed, I had to run from floppies *only* to get timer.device to crap
>out (which I never did before releasing the code, much to my displeasure). 
>
>I don't envy the person who has to find this bug...
>
>	-Rico

The bug is definitely in the timer device, and it has been fixed.
It will make it to the outside world in the next release (1.4).

In a way, I'm kind of embarassed about it: its my bug from way back.
In brief, the timer goes out of its way to be race free, but I missed
the case of the timer going off before I stopped it but after I
had turned off interrupts.  This meant the interrupt was held for
the next request (which turns out to sometimes be a trackdisk 3 ms STEP
request).

Apologies to all of you with trashed disks.

	Neil Katin

"You can't idiot proof anything; some idiots are just too clever"