Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!axion!ist!itcp
From: itcp@ist.CO.UK (Tom Parke)
Newsgroups: comp.sys.att
Subject: Re: Sys V/386/3.2 UNIX system getting hung (?)
Message-ID: <872@istop.ist.CO.UK>
Date: 14 Apr 89 09:40:37 GMT
References: <2379@maccs.McMaster.CA>
Organization: Imperial Software Technology, London, UK
Lines: 30

From article <2379@maccs.McMaster.CA>, by nusip@maccs.McMaster.CA (Mike Borza):
> This also concurs with my experience.  Our 386 with 4 MB of memory
> is used to develop X-Windows applications under ISC 386/ix (1.0.6).
> Based on analysis of sar output, we decided to increase, among
> other things, the number of disk buffes..  Under unpredictable
> circumstances, the system would slow to a crawl, sometimes dying and
> sometimes recovering without any intervention.  At other times, the
> system would just die, sometimes echoing characters typed at the
> console and serial terminals, sometimes not.  Reducing the amount of
> space allocated to some of the bigger kernel resources always restored
> reliable functionality for our application mix.  Prior to acquiring X,
> we were able to use substantially more disk buffers before
> encountering this problem.  Most interesting (and annoying).

I would have expected your system to be paged but cant help noting that
this behaviour is identical to that we new and loved on an old System V.0
68010 implementation.  The memory management was segmented and the above
pathalogical behaviour was observed whenever a processes segment size
approached the maximum available memory.  Further there was a bug in SBRK
such that a small increase in segment size over available memory was not
detected by SBRK as an error (though a large one was) and trying to swap in
the resulting over large segment hung the system.

A very similar bug existed in the MS_DOS loader (around version 2.0).
Plus ca change...

[Usual disclaimer: this represents only my hastily assembled opinion and
		   spelling, and not necessarily anyonelse's]

	Tom Parke (itcp@uk.co.ist)