Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hp-sdd!craigb
From: craigb@hp-sdd.hp.com (Craig Bosworth)
Newsgroups: comp.sys.ibm.pc
Subject: Re: FFC48.ARC - causes problems (for me)
Message-ID: <2695@hp-sdd.hp.com>
Date: 10 Oct 89 15:47:06 GMT
References: <3415@orion.cf.uci.edu>
Reply-To: craigb@hp-sdd.UUCP (Craig Bosworth)
Distribution: na
Organization: Hewlett Packard, San Diego
Lines: 28

In article <3415@orion.cf.uci.edu> manderse@orion.oac.uci.edu (Mark Andersen) writes:
>I just had a very disturbing experience. 

[... description of disk going funny after running a TSR in high memory
     with 386max loadhigh ...]


I had a similar experience not too long ago.  If you are using a disk cache,
I think you are having the same problem I did.  I didn't look into it *too*
carefully, but I think you having a conflict in extended (the linear kind, 
not the page switched kind) memory between 386max and your disk cache.

My solution was to get rid of 386max (I don't trust that damn thing).  Try
running the TSR again without the cache or without 386max.  If that works,
you're going to have to resolve the conflict manually by specifying on the 
command line what extended memory 386max and the disk cache can use.

Hope this helps...

BOS

"We don' need no steenkeeng memory management!!"

-- 
Craig Bosworth  (619) 592-8609           16399 West Bernardo Drive
Hewlett-Packard, San Diego Division      San Diego, CA  92127-1899
UUCP     : {hplabs|nosc|hpfcla|ucsd}!hp-sdd!craigb
Internet : craigb%hp-sdd@hp-sde.sde.hp.com (or @nosc.mil, @ucsd.edu)