the following on a i386 (2.6.24) kernel:
$ dtrace -n fbt::native_flush*:
Turns out one of the functions will be a "MOV %CR3,%EAX", and when
single stepping, the kernel will step the *next* instruction too.
The way dtrace is coded, we copy the instruction to be stepped to a buffer
(because the original has a 0xcc INT3 as the first byte), but the buffer
is null (0x00) filled. 0x00 isnt a good x86 instruction to randomly
execution, leading to a panic.
The cure seems to be to put a NOP in the copied instruction buffer, and
dtrace is happy to step over the double-instruction and we regain control
and carry on nice.
Strangely, this didnt happen on amd64 (probably because the first instruction
of a probe never corresponded to the equivalent instruction).