ACPI is still a problem on every operating system. Windows just hides some problems and breaks some time later. So most of the time it would be better to address your problems toward the manufacturer of your motherboard/laptop/bios.

Hardware with bad miss-implementations of ACPI are very common. Thankfully, most of their problems have been detected and coded around, and manufacturers have got a little better, but we cannot say that we have got every one of them.
Search for other problem reports and posts from other users with your hardware.

By the way, are you sure they are crashing with signal 12? Signal 12 is SIGUSR2, which is a generic number that is redefined by the process for any purpose it desires.
More common signals are 11 (SIGSEGV, Segmentation violation, similar to GPFs and Page Faults in the windows world - generally, bad ram, cache or other hardware), 6 (SIGABRT, general aborts, usually called when, for instance, a C++ exception is unhandled, or any other reason the program may want to kill itself abnormally) and 4 (SIGILL, illegal instruction - where you have compiled a program for the wrong processor). 7 (SIGBUS, buss error) also crops up occasionally.

__________________The only dumb question is a question not asked.
The only dumb answer is an answer not given.

I'm not trying to hijack the thread, but I'm seeing something similar with a very, very old computer (an early dual Athlon) with i386. Does loading with ACPI turned off eliminate all that code? If it does, then I have something else going on.

Turning off ACPI seems to solve to problem, the strange thing is that under a VMWare Virtual Machine (Win32), FreeBSD 7 crashes with the same errors. Is VMWare using some of my platform chipset hardware or it completely virtualizes all, excepting the CPU?