Help! Altos 5.3.1 fork is failing!

Larry Philps larry at hcr.UUCP
Mon Oct 16 23:16:55 AEST 1989


In article <506 at oglvee.UUCP> jr at oglvee.UUCP writes:
>We just recently "upgraded" [sic] an Altos 2000 from Xenix 5.2c to UNIX 5.3d.
>uname reports the operating system as 5.3.1.  We have 4M RAM and before the
>upgrade the machine just screamed.  Now we are paging like mad and getting
>sporadic fork failures.  The increased paging activity has my users bitching
>and moaning, but the fork failures are like a sniper loose in my system gunning
>down processes sporadically. ...
>
> NOTICE: getcpages - waiting for 1 contiguous pages
> NOTICE: getcpages - Insufficient memory to allocate 1 contiguous page -
				system call failed

I had this exact problem after I ported System 5.3.1 to a VAX (no comments
from the cheap seats please!).  Not very surprisingly, Release 3 requires
significantly more memory to run than Release 2.  So, like us, you were
probably running your system close to, but not over the memory trash point.
After upgrading, the extra OS memory requirement pushed you over the limit
and paging death occured.

Getcpages, is indeed get "contiguous" physical pages.  There are parts of the
paging system on some processors that require this.  The complaint about a
failure on 1 page simply means that ALL RAM was being used when the fork
appeared and the system needed a page to hold page tables or the like.

Now, for some reason unknown to me, in fork (procdup actually), dupreg is
called with arguments that specify that it is not to sleep.  I couldn't come
up with any sensible reason why this had to be, so I changed the call to
allow sleeps.  The fork failure problems simply went away, and no other
problems manifested.

So, what you should do is bitch to your supplier, and if you are very daring,
binary patch your kernel and change the second argument to "dupreg", as
called from "produp" (there is only one such call) to be a 0 rather than a 1,
and try things out.  It works on a vax, you can give it a try on your Altos
if you are brave.

By the way, this did NOT solve our trashing problems, we only got rid of that
by buying more memory for the machine.  Bet you are really happy to hear that!

----
Larry Philps                             HCR Corporation
130 Bloor St. West, 10th floor           Toronto, Ontario.  M5S 1N5
(416) 922-1937                           {utzoo,utcsri}!hcr!larry



More information about the Comp.unix.i386 mailing list