CRONEJP@UREGINA1.BITNET (Jonathan Crone) (06/15/88)
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) Now being a system administrator at heart, I frequently use Taskx to twiddle priority of processesing running.... (natch i don't stomp on system stuff except to make any system task with a priority of 10 or less, get at least 10.... (I'm paranoid) Now with Handshake (most often because of my frequent use of it) running i would frequently get a major visit from the guru, or system sluggishness after moving the mouse after a screen blank... as in i'd walk away from the system, go do something, find the screen blank, flick the mouse to bring the system back to life, and watch as the system gurued with a 0003, or got pissed as the mouse would suddenly react as if someone had poured crude oil all over the screen.... (can you say... pawing the mouse like crazy and getting 1 cm per second speed?) (I KNEW you could) Eventually this crashes thes sytem as well. Now being brain damaged, i figure... well SOMETHING is messing with this system. I look at the priority lists with Taskx after a reboot and notice something amusing... Dmouse was running at priority 0. Handshake was running at 1. I let the screen blank... flicked the mouse, and guru. I reboot. set Dmouse to priority 2... wait on screen blank. flick... and no guru. I put a mess of other stuff in... and noticed the same effects... Dmouse seems happy if it seems to have a priority higher than other user tasks. I was begining to think that i was on drugs, as no one else had reported any bugs like this on the net... and with half the net singing hosannas to Dmouse, i knew that someone would have reported this... SO i didn't say anything. Then my friend with an A2000, called me up to bitch about how Dmouse and word perfect or anything else was crashing his system after screen blanks. i said to him... You're flicking the mouse???? After a screen blank??? Yup... word perfect??? yup... Handshake??? Yup... <---- bingo i think. I asked him to remodel his startup sequence to add the CLI ChangeTaskPri program in it so that it would set a priority of 3 to dmouse before he ran it.... (ie.. CHANGETASKPRI 3 RUN DMOUSE (The task for Dmouse inherits the priority) CHANGETASKPRI 0 (set to normal again). He stopped having gurus... thats two people... one a semi techie (me..) and one an amiga neophyte counting on me for assistance (silly him) :-) Can someone tell me if i'm dreaming or what???? Incidently i also noticed this behavior with a program called CLI wizard (it sets its priority to 20!!!!!!) (to say the least it got chopped to 1) (as in the guru thingy occurred before i started using taskx regularly to twiddle performance) Thanks Jonathan -------------------------------------------------------------------- Jonathan P. Crone Vice President, AURA, (Amiga Users of Regina Associated.) (Regina, Sask. Canada ) (eh???) CRONEJP@UREGINA1.BITNET ....rutgers!mimsy!uunet!mcl!cronejp come on now.... does ANYONE give a damn about what i have to say? --------------------------------------------------------------------
Skywalker@cup.portal.com (06/16/88)
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 --