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"