08:54 <gibbs_> there have been other reports of this issue in the past (5.X and 6.X), but I haven't seen an responses.
08:54 <gibbs_> Perhaps I just need to roll my 6.2 based system forward.
08:54 <gibbs_> panic(c073d5bb,e5147c10,c06d7d3a,c15c4f00,e1d76000,...) at panic+0x70
08:54 <gibbs_> vm_page_dirty(c15c4f00) at vm_page_dirty+0x39
08:54 <gibbs_> pmap_remove_pte(c081af00,bff875d8,e1d76000,e5147c2c) at pmap_remove_pte+0xa2
08:54 <gibbs_> pmap_remove(c081af00,e1d76000,e1db8000) at pmap_remove+0x120
08:54 <gibbs_> vm_map_delete(c103e0c0,e1d76000,e1db8000,c103e0c0,c073c54b,1d2) at vm_map_delete+0x159
08:54 <gibbs_> kmem_free_wakeup(c103e0c0,e1d76000,41400,0,e5147cdc,...) at kmem_free_wakeup+0x38
08:54 <gibbs_> exec_free_args(e5147cb4,e1d76000,e1d76000,e1d76022,e1d7604c,...) at exec_free_args+0x1e
08:54 <gibbs_> execve(c526a000,e5147d04) at execve+0x41
08:54 <gibbs_> syscall(3b,3b,3b,0,0,...) at syscall+0x22f
08:55 <gibbs_> Xint0x80_syscall() at Xint0x80_syscall+0x1f
08:55 <gibbs_> --- syscall (0, FreeBSD ELF32, nosys), eip = 0x28056b68, esp = 0xbfbfeeb4, ebp = 0 --

08:56 <gibbs_> I'm guessing I have the same thing as in this report: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-03/0754.html
09:32 <gibbs_> BTW, these systems are setup without swap if that makes any difference.

09:10 <EvilPete> core.txt.0:fault virtual address        = 0x0
09:10 <EvilPete> core.txt.1:fault virtual address        = 0x76fa759e36d9
09:10 <EvilPete> core.txt.3:fault virtual address        = 0xffff800000092ff8
09:10 <EvilPete> core.txt.4:fault virtual address        = 0x76fa7f3fd21a
09:10 <EvilPete> core.txt.5:fault virtual address        = 0xffff8000000c7ff8
09:10 <EvilPete> core.txt.7:fault virtual address        = 0xffff8000001dfff8
09:10 <EvilPete> core.txt.8:fault virtual address        = 0xffff8000000ccff8
09:10 <EvilPete> core.txt.9:fault virtual address        = 0x76fa78ab0429
09:10 <EvilPete> core.txt.10:fault virtual address       = 0x76fa7ca4ddca
09:10 <EvilPete> core.txt.11:fault virtual address       = 0xffff800000120ff8
09:11 <EvilPete> the *ff8 is alarming, because that corresponds to the recursive pte map area

09:11 <EvilPete> ffff800000000000 A loc_PTmap
09:11 <EvilPete> ffff804000000000 A loc_PDmap

the user vm addresses that correspond to the fff8000*ff8 addresses are:
09:23 <EvilPete> 125FF000
09:24 <EvilPete> 18FFF000
09:24 <EvilPete> 3BFFF000
09:24 <EvilPete> 199FF000
09:25 <EvilPete> 241FF000

all are the very last page in a 2MB block.  too many coincidences.

ALso.
core.txt.0:current process              = 56891 (perl5.6.1)
core.txt.1:current process              = 25241 (perl5.6.1)
core.txt.2:current process              = 626 (syslogd)
core.txt.3:current process              = 41035 (perl)
core.txt.4:current process              = 26078 (perl5.6.1)
core.txt.5:current process              = 6897 (sh)
core.txt.7:current process              = 12432 (sendmail)
core.txt.8:current process              = 91564 (sendmail)
core.txt.9:current process              = 18252 (perl5.6.1)
core.txt.10:current process             = 68649 (perl5.6.1)
core.txt.11:current process             = 47366 (sendmail)

compare that to the fault virtual address map above.
0	perl	 0x0
5	sh	 0xffff8000000c7ff8
3	perl	 0xffff800000092ff8
1	perl	 0x76fa759e36d9
4	perl	 0x76fa7f3fd21a
9	perl	 0x76fa78ab0429
10	perl	 0x76fa7ca4ddca
7	sendmail 0xffff8000001dfff8
8	sendmail 0xffff8000000ccff8
11	sendmail 0xffff800000120ff8

not a particularly big sample, but there is a hint of consistency there.