Path: utzoo!attcan!uunet!portal!cup.portal.com!Skywalker
From: Skywalker@cup.portal.com
Newsgroups: comp.sys.amiga
Subject: Re: Random Gurus and Dmouse
Message-ID: <6562@cup.portal.com>
Date: 16 Jun 88 07:07:31 GMT
References: <8806150650.AA02347@jade.berkeley.edu>
Organization: The Portal System (TM)
Lines: 30
XPortal-User-Id: 1.1001.3640

CRONEJP@UREGINA1.BITNET writes:
>I'm posting this because many people may find this of use in
>their hunt for that silly bugger in a turban who keeps throwing
>wierd numbers out at us.
>
>I normally run as a system configuration, the following..
>a 650k VD0:, Handshake V1.60b, Taskx , RSLClock1.3, Dmouse 1.06, and
                                        ^^^^^^^^^^^
>Gomf 2.2.   (on an A1000, 2 drive, 2 meg Micron power supplied memory)

Quite a while back (shortly after RSLClock1.3 came out), there was a rash
of people complaining about random guru's, corrupted disks, etc...
after much testing, several people reported that the random guru's and/or
corrupted disks stopped happening after removing RSLClock1.3 from their
startup-sequence. Since I was also having similar problems, I removed
RSLClock1.3, and my ami got cured of its sickness, too. The problem
apparently arose only if you had other programs that used timer.device,
such as PopCLI (now mostly replaced by dmouse) or almost ANY terminal
program: the timer.device (aka Delay(0)) bug got triggered frequently.

You may have also noticed that RSLClock1.3 is something of a CPU cycle
hog -- (it's been a while, but...) about 15-20% of the cpu cycles were
going to support that "little" clock (according to "pm" anyway).

I would suggest that a better long-term solution would be to find a
different clock program to run, and immediately remove RSLClock1.3.
(I did run v1.4 for a while, it didn't seem to have that problem).

	my 0.02 worth (from an old 1000 owner)
		-- scott --