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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
