Xref: utzoo comp.unix.i386:831 comp.unix.wizards:18732 Path: utzoo!attcan!ncrcan!hcr!larry From: larry@hcr.UUCP (Larry Philps) Newsgroups: comp.unix.i386,comp.unix.wizards Subject: Re: Help! Altos 5.3.1 fork is failing! Message-ID: <2296@hcr.UUCP> Date: 16 Oct 89 13:16:55 GMT References: <506@oglvee.UUCP> Reply-To: larry@zeus.UUCP (Larry Philps) Organization: HCR Corporation, Toronto Lines: 43 In article <506@oglvee.UUCP> jr@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