Bug 108121

Summary: [pmap] pmap.c panic message references a sysctl that doesn't exist
Product: Base System Reporter: Bill Moran <wmoran>
Component: kernAssignee: Ade Lovett <ade>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Bill Moran 2007-01-19 15:50:20 UTC
See the following thread on -questions@ for some information:
http://lists.freebsd.org/pipermail/freebsd-questions/2007-January/140286.html

It appears as if pmap.c contains an error message suggesting the user
increase a sysctl that doesn't exist:
panic("no pv entries: increase vm.pmap.shpgperproc");

This panic string exists in the alpha, amd64, i386, and ia64 versions of
pmap.c.  It does not exist in the arm version.

`sysctl -a | grep pmap` does not list any sysctls.

The usual answer to this is to rebuild a kernel with PMAP_SHPGPERPROC
set to a higher value.

Not sure why the sysctl isn't available.

Fix: 

My preference would be to actually make the value tunable via sysctl,
but I have no idea how difficult that would be.

If it can not be made available via sysctl, the message should probably
be changed to recommend rebuilding the kernel, as is done in
sys/vm/vm_pageout.c
How-To-Repeat: Not sure how to reliably create the panic situation, but I don't believe that's the real issue.  grepping the sysctl and the source should provide the rest of the information.
Comment 1 Ade Lovett freebsd_committer freebsd_triage 2007-01-30 01:04:41 UTC
State Changed
From-To: open->closed

The message is correct.  However, it is *NOT* a sysctl, rather it is a 
tunable that can be set in /boot/loader.conf eg: 

vm.pmap.shpgperproc=1000 

Making this a sysctl, with the ability to dynamically change it whilst 
the system is running would be Exceptionally Hard[tm]. 

One could possibly make a case for providing a read-only sysctl, though 
it is likely to be of very limited use, since pv exhaustion is not by 
any means a typical occurance. 


Comment 2 Ade Lovett freebsd_committer freebsd_triage 2007-01-30 01:04:41 UTC
Responsible Changed
From-To: freebsd-bugs->ade

Since I provided the specific "fix" (in terms of an appropriate panic, 
rather than letting the kernel wander off into la-la land as was the 
case previously), I'll assume (some of ;) the responsibility...