Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga
Subject: Re: Ami crashes, RAD:
Message-ID: <6986@batcomputer.tn.cornell.edu>
Date: 11 Dec 88 21:12:59 GMT
References: <27024@ucbvax.BERKELEY.EDU> <22935@sgi.SGI.COM> <3064@sugar.uu.net> <12413@cup.portal.com>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Distribution: na
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 22

In article <12413@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
>Peter says he has no problems with his startup sequence:
>
>	example deleted
>
>Peter, perhaps it is the fact that you have several megs of Ram.  I suspect
>that some of the crashes I have experienced have been memory related.

I had problems with rad:, ram: and vd0: co-existing on my 2.5 Meg A1000.
Usually the system would just hang after a write to ram:.  After much
futzing about, I discovered that, at least on my system, these ram-disks
are very sensitive to the order they are mounted in.  If I reference ram:
(i.e., copy something to it, or dir it), then mount rad: and reference it,
and then mount vd0: and reference it, the system seems very nicely stable.
If I vary the order (in particular, if I mount vd0: before rad:), it
usually won't even complete the startup-sequence (it hangs in a setenv,
with env: is assigned to ram:env).  This is a bit of nuisance, but I guess
I'm getting used to it.  I am also totally clueless why it works one way
and not the other.

-Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-Wilson Lab, Cornell U.