[pups] Strange problems on an uPDP 11/53+

[Steven M. Schultz]

Hi -

> From: Martijn van Buul <pino at dohd.org>
> After 52 days, my uPDP 11/53+ has suddenly been acting rather strange.
> /usr/include got 'replaced' by /usr/new, to be precise. At the time,

	Oops!   

> I was the only user. Seeing this, I immediately halted the system,
> expecting a load of file system errors upon boot. None showed up, and
> /usr/include is back to itself again. However, programs which *used*
> to be running perfectly (like my work-in-progress ps) suddenly fail,
> with a "not enough memory for saving info".

> Any hints?

	How much memory is on the system now after the reboot.   The only
	thing that pops into mind is that the system is running without
	enough memory.    If part of the memory on the system dropped out
	earlier that would (possibly) explain the strange behaviour was
	seen.   Rebooting/reseting the system would cause the system to
	recount memory.

	A program can get 'ENOMEM' as an error two ways: 1) exceeding the
	maximum 64KB dataspace (stack + data) or 2) the system has run out
	of swap or the maps ('coremap' and/or 'swapmap') have become too
	fragmented.

	Two commands that can be useful in obtaining more information are

		sysctl hw

	and 

		pstat -s

	"sysctl hw" will give several lines of output - the two you'd be
	interested in are 

	hw.physmem = 2097152
	hw.usermem = 415744

	'physmem' is the amount of memory physically present and 'usermem' is
	the amount current free and available for user programs.

	"pstat -s" will give a swap space usage summary.

	Steven Schultz
	sms at Moe.2bsd.com

Received: (from major at localhost)
	by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id SAA71926
	for pups-liszt; Tue, 6 Feb 2001 18:41:36 +1100 (EST)
	(envelope-from owner-pups at minnie.cs.adfa.edu.au)