Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!rutgers!cmcl2!husc6!rice!sun-spots-request
From: sgf@lfm.brown.edu (Sam Fulcomer)
Newsgroups: comp.sys.sun
Subject: Re: panic: memall intrans|want is MAXUSERS problem
Message-ID: <8812121626.AA01331@lfm.brown.edu>
Date: 20 Dec 88 07:47:03 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 33
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 12 Dec 88 11:26:31 EST
X-Sun-Spots-Digest: Volume 7, Issue 63, message 10 of 11

yes, MAXUSERS needs to be changed, but to a lower, not higher value. The
problem is that in older (3.X, maybe X < 5?) OS versions the kernel zero
routine didn't properly zero buffer space over some (don't remember)
address (the beast was using some 16(?)-bit value in addressing). (This
only occurs if you toss a lot of memory into the machine; more memory,
more buffer space.) 

Ther memory wasn't properly zeroed, and memall(oc) would see it as already
allocated.

The simplest solution is to run a kernel with the fix (I think there's a
patch to the kernel's bzero() around). The better fix is to apply local
kludges to the already kludged param.c. My own feeling is that MAXUSERS
should be kept low (like, you know <= 4). The other values (and
determining formulas) should be adjusted as needed for the particular
system. There's just too much there to depend on one variable.

The ugliest thing that happens if you bump MAXUSERS up is that NPROC gets
ridiculously high. Try:

#! /bin/csh

while (1)
	this_file &
end

then reboot your machine after you lose patience with an uptime.  

param.c makes about as much sense as the irs' formulae for
income-averaging.

sam
sgf@csc.brown.edu