From owner-freebsd-current Fri Jul 23 11:14: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 7785514BF9 for ; Fri, 23 Jul 1999 11:13:59 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA25783 for ; Fri, 23 Jul 1999 11:13:17 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 11:13:17 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-current@freebsd.org Subject: PMAP_SHPGPERPROC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Using two -current machines, both dated 7/16 I got the following message in my log file, which I think explains the weird spontaneous reboots I've been getting. /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Having read LINT I see the following: # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". So I increased from the default 200 to 300, and rebooted without incident. I have 512 megs of ram in both machines, running dual PIII 500's. So far I haven't seen any more of those error messages, although they tend to show up after the machines have been in service for a while. More than anything else I'm looking for some guidance on what I'm dealing with here, and possible causes for it to be getting so far out of whack. To start with, what are pv entries? And how high is "safe" to go with this PMAP_SHPGPERPROC value if I get some more of those error messages? These boxen's sole job at this point is to process scripts for this third party CGI scripting language called miva. I would be very ready to attribute blame for the problem to miva itself, or a rampant user script, but it would be nice to know where to look. Also, in case it matters these boxes are heavy amd/nfs client consumers, mounting all of the remote user directories to get the data from. Finally, I'm also seeing a lot of these periodically: /kernel: in_rtqtimo: adjusted rtq_reallyold to 1600 however I seem to recall from previous experience with the Intel etherexpress cards that some of those are normal. Any help, ideas or suggestions are welcome and appreciated. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message