generic_timer.c installs interrupt handlers for up to four timer interrupts, causing those interrupts to be enabled on the local PIC. But the handler that it installs assumes that all interrupts come from a specific timer (either the physical one on 32bit or the virtual one on 64bit). If an interrupt occurs on the other timer, then the interrupt is never masked or cleared, so a CPU is put into a permanent interrupt handling loop; this is commonly observed on RPI2 platforms at least. The unexpected interrupt can occur because while the driver attach routine tries to mask off both the physical and virtual (on 32bit) interrupts, it does this on only one CPU, when in fact each CPU has its own timer. I have tested a crude workaround (not installing handlers for the unused interrupts) which fixes the observed problems as far as I can determine. This bug could potentially apply on 64bit as well, but I am not in a position to test that.
I have posted https://reviews.freebsd.org/D19871 for review as a solution to this problem; it implements the suggested fix of not installing handlers for the unused timers).
This was fixed in base r346312, MFC'd to stable/12 as base r346500, stable/11 as base r346561, but apparently nobody bothered to update the bug then or mention it in the commit message.