dtrace profile timers still unstable?

In the past, I've had little luck using the DTrace profile timers on FreeBSD 
for much without crashes, and this morning was no different.  I attempted to 
use the following(ish) script:

   profile-1ms
   {

           _at_data[stack()] = count();
   }


The result was:

spin lock 0x849747d8 (cyclic cpu) held by 0x85442b40 (tid 100539) too long
panic: spin lock held too long

0  doadump () at pcpu.h:246
#1  0x8089b5bf in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2  0x8089b8a2 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3  0x8088afaf in _mtx_lock_spin_failed (m=0x0)
     at /usr/src/sys/kern/kern_mutex.c:490
#4  0x8088b035 in _mtx_lock_spin (m=0x849747d8, tid=2220091648, opts=0,
     file=0x8a717a45 
"/usr/src/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at 
/usr/src/sys/kern/kern_mutex.c:526
#5  0x8088b7d1 in _mtx_lock_spin_flags (m=0x849747d8, opts=0,
     file=0x8a717a45 
"/usr/src/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at 
/usr/src/sys/kern/kern_mutex.c:246
#6  0x8a716f97 in cyclic_clock () from /boot/kernel/cyclic.ko
#7  0x80bce876 in lapic_handle_timer (frame=0x842c6c34)
     at /usr/src/sys/i386/i386/local_apic.c:777
#8  0x80bc61cf in Xtimerint () at apic_vector.s:108
#9  0x80bba455 in acpi_cpu_c1 () at 
/usr/src/sys/i386/acpica/acpi_machdep.c:554
#10 0x804ff24c in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:921
#11 0x80bcff2b in cpu_idle_acpi (busy=1)
     at /usr/src/sys/i386/i386/machdep.c:1236
#12 0x80bd18db in cpu_idle (busy=1) at /usr/src/sys/i386/i386/machdep.c:1324
#13 0x808bf81e in sched_idletd (dummy=0x0)
     at /usr/src/sys/kern/sched_ule.c:2562

In the past, I've had similar experiences, although possibly different panics. 
I wonder if we should just disable the profile provider in 8.0 to prevent 
similar footshooting by others?  Or perhaps someone with some dtrace internals 
interest could investigate?

(I've seen panics with it pretty deterministically on i386 and amd64)

Robert N M Watson
Computer Laboratory
University of Cambridge