Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: shenkin@cunixc.cc.columbia.edu (Peter S. Shenkin)
Newsgroups: comp.sys.sun
Subject: "Not enough memory" on Sun 386i/250 under SunOS 4.0.1
Keywords: 386i
Message-ID: <8902231707.AA12812@columbia.edu>
Date: 7 Mar 89 08:20:39 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 43
Approved: Sun-Spots@rice.edu
Original-Date: Thu, 23 Feb 89 09:21:20 EST
X-Sun-Spots-Digest: Volume 7, Issue 184, message 13 of 16

I have a Sun 386i/250 (8Mb main memory, 327 Mb hard disk).  Since
upgrading to SunOS 4.0.1, I can't get large programs ("size" > ~6 Mbytes)
to load; the message is "Not enough memory."  This is a standalone
workstation, and the only things running, aside from miscellaneous
daemons, are a shelltool and sunview.  I did not have the problem under
SunOS 4.0.

These are fortran programs, and to check things out I tried the following,
to no avail:

	1.  Re-compiled and linked the program
	2.  Re-booted the machine (it knows about all 8 Mbytes)
	3.  Doubled the size of the swap-space, from 16.3 to 32.6 Mbytes,
	    and made sure this took place using format> partition> print.
	    (See FLAME below on repartitioning operation... grrr!)
	4.  Made sure there are no quotas on the system
	5.  Wrote a series of fortran programs containing the line
		INTEGER I( x )
	    When x gets large enough so that the "size" of the program
	    exceeds about 6 Mbytes, the "Not enough memory" message
	    appears when an attempt is made to execute it.
	6.  Asked several UNIX gurus.  They're stumped too.

If you have any insight into what might be causing this, or what I should
try next, please send me email, or reply to this newsgroup, though that
takes longer, and I will in any case post a followup telling what worked.

Thanks,
	Peter S. Shenkin:    shenkin@cunixc.cc.columbia.edu
	Department of Chemistry, Barnard College.

FLAME:  (Re: repartitioning the system disk)

Unless I'm missing something, the instructions in Sun386i Advanced
Administration, Section 7.2-3, are simply wrong.  These indicate that
after increasing /dev/rootb (swap area) at the expense of /dev/rooth
(/files), the system should boot uneventfully from tape.  In fact, the
boot fails in ypserv, with some message to the effect that yp can't find
something.  (Sorry, I neglected to write the message down.)

Turns out that the system needs files somewhere deep within /files/cluster
to boot.  The workaround was to mount and restore /files in single user
mode.  Multi-user then comes up uneventfully.