panic on sparc64

hello,

recent -current often panics with the following stack trace on sparc64.

is this something new? or has it been fixed already?

thanks,
max


panic: mutex vm page queue mutex not owned at
/usr/src/sys/sparc64/sparc64/pmap.c:1768
cpuid = 0
KDB: enter: panic
panic: from debugger
cpuid = 0
Uptime: 9h36m23s
Dumping 256 MB (2 chunks)
  chunk at 0: 134217728 bytes |

#0  0x00000000c0280318 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240             savectx(&dumppcb);
(kgdb) where
#0  0x00000000c0280318 in doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0x00000000c0280d40 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:409
#2  0x00000000c0281124 in panic (fmt=0xc06454f0 "from debugger")
    at /usr/src/sys/kern/kern_shutdown.c:563
#3  0x00000000c009ed28 in db_panic (addr=3224044552, have_addr=0, count=-1,
    modif=0xceff6868 "") at /usr/src/sys/ddb/db_command.c:433
#4  0x00000000c009fc74 in db_command_loop ()
    at /usr/src/sys/ddb/db_command.c:401
#5  0x00000000c00a2d34 in db_trap (type=Variable "type" is not available.
) at /usr/src/sys/ddb/db_main.c:222
#6  0x00000000c02b00d4 in kdb_trap (type=107, code=0, tf=0xceff6cd0)
    at /usr/src/sys/kern/subr_kdb.c:502
#7  0x00000000c0559990 in trap (tf=0xceff6cd0)
    at /usr/src/sys/sparc64/sparc64/trap.c:318
#8  0x00000000c0071000 in tl1_trap ()
#9  0x00000000c02b0408 in kdb_enter (msg=0x12 <Address 0x12 out of bounds>)
    at /usr/src/sys/kern/subr_kdb.c:307
#10 0x00000000c02b0408 in kdb_enter (msg=0xc066c008 "panic")
    at /usr/src/sys/kern/subr_kdb.c:307
#11 0x00000000c02810ec in panic (fmt=0xc066a978 "mutex %s not owned at %s:%d")
    at /usr/src/sys/kern/kern_shutdown.c:547
#12 0x00000000c0272894 in _mtx_assert (m=0xc07e1598, what=1,
    file=0xc069aaf0 "/usr/src/sys/sparc64/sparc64/pmap.c", line=1768)
    at /usr/src/sys/kern/kern_mutex.c:623
#13 0x00000000c0551660 in pmap_page_is_mapped (m=0xfffff80007be2768)
    at /usr/src/sys/sparc64/sparc64/pmap.c:1768
#14 0x00000000c04e6f14 in vm_page_free_toq (m=0xfffff80007be2768)
    at /usr/src/sys/vm/vm_page.c:1258
#15 0x00000000c04e72d8 in vm_page_free (m=0xfffff80007be2768)
    at /usr/src/sys/vm/vm_page.c:498
#16 0x00000000c055bb84 in uma_small_free (mem=0xfffff80001252000, size=8192,
    flags=8 '\b') at /usr/src/sys/sparc64/sparc64/vm_machdep.c:505
#17 0x00000000c04d3d78 in zone_drain (zone=0xfffff80007fec900)
    at /usr/src/sys/vm/uma_core.c:767
#18 0x00000000c04cf194 in zone_foreach (zfunc=0xc04d3aa0 <zone_drain>)
    at /usr/src/sys/vm/uma_core.c:1495
#19 0x00000000c04d41c8 in uma_reclaim () at /usr/src/sys/vm/uma_core.c:2670
#20 0x00000000c04eaf20 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:696
#21 0x00000000c025bf24 in fork_exit (callout=0xc04ea560 <vm_pageout>, arg=0x0,
    frame=0xceff7880) at /usr/src/sys/kern/kern_fork.c:796
#22 0x00000000c00711f0 in fork_trampoline ()
#23 0x00000000c00711f0 in fork_trampoline ()
Previous frame identical to this frame (corrupt stack?)