Path: utzoo!attcan!uunet!snorkelwacker!usc!cs.utexas.edu!asuvax!mcdphx!teroach.UUCP!stan From: stan@teroach.UUCP (Stan Fisher) Newsgroups: comp.sys.amiga Subject: Re: 2091 problems (was JrComm 1.0) Message-ID: <13242@mcdphx.phx.mcd.mot.com> Date: 20 Jul 90 16:07:09 GMT References: <1500@faatcrl.UUCP> <25990@usc.edu> <1509@faatcrl.UUCP> <26053@usc.edu> <1518@faatcrl.UUCP> Sender: listen@mcdphx.phx.mcd.mot.com Reply-To: stan@teroach.UUCP (Stan Fisher) Distribution: na Organization: Motorola Microcomputer Division, Tempe, Az. Lines: 32 In article <1518@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >papa@pollux.usc.edu (Marco Papa) writes: > >>Maybe I should have qualified 'stomping' as BOTH reading and writing >>location 0. On an A1000, ZeroMung & Co. will help you to find writing loc 0 >>problems. No way for you to find 'reading loc 0' problems. > >Think about this again. On a machine with a 2091 and a still stomped location >zero, you get a semephore guru. If I stomp on location zero with a non-zero >value using an A1000 and then run JR-Comm, it does not guru. This is what is >so baffling. > > -jack- I seem to be one of the lucky ones that has had no problems since I followed the procedure for changing which FFS is being used on my 2091... My problem, and one I've heard of elsewhere, which doesn't seem to be being addressed by Commodore is when you've got multiple fast SCSI devices (drives) and do copies between the two drives (physical drives, not just partitions) the whole system hangs with the drive access LED stuck on. The only way out is to re-boot and then wait for the validator to do it's thing. There seems to be a REAL problem with the SCSI bus arbitration on the 2091! Can't someone at Commodore comment on this? I already posted this problem to c.s.a.t and heard nothing back. Stan Stan Fisher - stan@teroach.phx.mcd.mot.com - asuvax!mcdphx!teroach!stan Motorola Microcomputer Division, Tempe, Arizona - Voice (602) 438-3228 Call our User Group BBS "M.E.C.C.A." running Atredes 1.1 @ (602) 893-0804