> This one seems strange to me, so I figured I'd pass it on to the list.  After 
> learning about these commands I looked in /var/db, and kvm.db had a last 
> modified date of 8/23/1999(!!!).  It certainly should have run at boot on the 
> 100+ reboots on at least 5 different -current kernel/userland updates since 
> then.
> 
> So I ran 'kvm_mkdb' by hand as root, nothing changed.  It didn't touch 
> /var/db/kvm.db.  I then moved the current kvm.db out of the way and re-ran 
> kvm_mkdb, and it created a new file that makes iostat/vmstat/netstat happy.


The way kvm_mkdb determines that kvm.db is out-of-date is to read the
kernel version string from /dev/kmem at the location where it was at
the time that kvm.db was last built (that location is also stored in kvm.db).

Normally, when a new kernel is booted that version string is updated
and possibly moved to a different location (and the old location will
have been filled with other random data from the new kernel), which
will trigger a kvm.db rebuild.

Now, sparc (ELF format) programs (including the kernel) exhibit a 64KB
virtual address space gap between the end of text and the start of the
data segment. About this gap, the current pmap bootstrap code knows nothing..

Besides going completely to waste, it also is the case that this memory area
isn't touched at all neither by the machine PROM nor by the kernel image
loader. So, as kernels grew (they never shrink, do they?) some previous kernel
version string became stuck in that memory gap, from where it was read every
time kvm_mkdb was run. 

You must never have power-cycled your machine in the last year and a half too..

-pk