Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!mips!pacbell.com!ucsd!rutgers!cbmvax!amix!vanth!jms From: jms@vanth.UUCP (Jim Shaffer) Newsgroups: comp.sys.amiga.hardware Subject: Re: system locking up when accessing floppies Message-ID: Date: 6 Jan 91 17:36:57 GMT References: <1398@tardis.Tymnet.COM> Lines: 37 In article <1398@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article jms@vanth.UUCP (Jim Shaffer) writes: >>I've been having a problem with my A500 for a while now, but it's just >>gotten frequent enough to make me want to do something about it. The >>system will lock up sometimes when I'm accessing my floppy drives. The >>drives will remain spinning and all I can do is reboot the machine. > >This problem is common with Amigas with the 1.2 ROMs. The usual case is >when a program is writing to one floppy at the same instant that AmigaDOS >decides to click the other floppy (to see if it's still empty). I got killed >several times while trying to backup my harddisk last year. > >The workaround: Keep a floppy disk in all drives at all times. (No clicking.) >The fix: Go to an Amiga dealer and get new ROMs installed. But, I usually *do* have a floppy in all drives at all times. The problem has hit me several times when changing floppies -- it locks up as soon as it tries to validate the just-inserted disk -- BUT it's also hit when I've had disks in my drives for an entire session. Say I have a program that, when it exits, writes a file to DF1: and another to DF0:. DF1: spins and steps and the file is written, but just as DF0: starts spinning, and before it steps, the system locks. DF1: is *still* spinning and there's about a 50% chance that the file written to it will be either open or non-existant. There is never a file on DF0: -- the lock-up seems to take place as soon as the spindle motor comes on, from what I've seen so far. You're right that I'm running the 1.2 ROM, but I'm using SetPatch from 1.3.2 and I'm also using the latest version of TrackSalve, which is supposed to patch trackdisk.device to prevent the bug you mentioned. So I sort of doubt that that's the problem. The increasing frequency of this over both uptime and lifetime also points to hardware. -- paper : James Shaffer Jr., 37 Brook Street, Montgomery, PA 17752 uucp : uunet!cbmvax!amix!vanth!jms (or) rutgers!cbmvax!amix!vanth!jms domain: jms%vanth@amix.commodore.com CompuServe: 72750,2335 quote : ATTENTION ALL PLANETS OF THE SOLAR FEDERATION: WE HAVE ASSUMED CONTROL