Recurring kernel panic 10.7.5 iMac

Question

I've been encountering irregular, but consistent kernel panics for the past three months.  I'm submitting reports, but there don't seem to be any updates in the channel that have affected the situation.  I'd like to get to the bottom of this.  The machine was completely reinstalled from media one month ago, and the situation has not changed.  Whether it's a software or hardware issue, there should be some indication.
I have two panic logs.  Panics occurred at:
new_vnode vfs_subr.c:3717. "free vnode still referenced".
pmap_pv_remove: pmap_internal.h:813. "pv not on hash"
This looks like memory corruption.  If it's a kernel software issue, I have no idea where to start.  If it's a defective memory issue, is there an on-board test to diagnose this?
Any assistance would be appreciated.  Thanks.

Answer 1

That panic was not caused by third-party software. If the problem is recurrent, the possibilities are:
A stale or corrupt kernel cache
A damaged OS X installation
A fault in a peripheral device, if any
Corrupt non-volatile memory (NVRAM)
An internal hardware fault (including incompatible memory)
An obscure bug in OS X
You may already have ruled out some of these.
Rule out #1 by booting in safe mode and then rebooting as usual. Note: If FileVault is enabled on some models, or if a firmware password is set, or if the boot volume is a software RAID, you can’t do this. Post for further instructions.
You can rule out #2 and #3 by reinstalling the OS and testing with non-essential peripherals disconnected and aftermarket expansion cards removed, if applicable. Sometimes a clean reinstallation may solve a problem that isn't solved by reinstalling in place.
Corrupt NVRAM, which rarely causes panics, can be ruled out by resetting it.
If your model has user-replaceable memory, and you've upgraded the memory modules, reinstall the original memory and see whether there's any improvement. Be careful not to touch the gold contacts. Clean them with a mild solvent such as rubbing alcohol. Aftermarket memory must exactly match the technical specifications for your model.
The Apple Hardware Test or Apple Diagnostics, though generally unreliable, will sometimes detect a fault. A negative test can't be depended on. Run the extended version of the test.
In the category of obscure bugs, reports suggest that FileVault may trigger kernel traps under some unknown conditions. Most, though not all, of these reports seem to involve booting from an aftermarket SSD. If those conditions apply to you, try deactivating FileVault.
Connecting more than one display is another reported trigger for OS X bugs.
If your system is not fully up to date, running Software Update might get you a bug fix.
In rare cases, a malformed network packet from a defective router or other network device can cause panics. Such packets could also be sent deliberately by a skillful attacker. This possibility is something to consider if you run a public server that might be the target of such an attack.
If none of the above applies, make a "Genius" appointment at an Apple Store to have the machine tested. You may have to leave it there for several days. There isn't much point in doing this unless you can reproduce the panic, or if you can't, it happens often enough that it's likely to be repeated at the store. Otherwise you may be told that nothing is wrong.
Print the first page of the panic report and bring it with you.
Back up all data on the internal drive(s) before you hand over your computer to anyone. If privacy is a concern, erase the data partition(s) with the option to write zeros* (do this only if you know how to restore, and you have at least  two independent backups.) Don’t erase the recovery partition, if present.
Keeping your confidential data secure during hardware repair
*An SSD doesn't need to be zeroed.