Oh, this is bad, what a bummer.
Have you checked the memory?
It would be best to run Memtest86(+) for some days, or until errors occur.
I've never heard of a memory problem causing such a specific reproducible error in an I/O subsystem. On the other hand, it's good to validate everything again. Or possibly for the first time.
The chassis itself should be no problem, if all necessary mainboard standoffs are mounted and fastened, and no excess standoffs produce a short circuit.
Some weeks or so ago, someone here had a problem that was caused by a standoff without a corresponding mounting hole on the board...
Well, that's a good point. There's something unusual going on here.
Check for loose screws wedged behind the board. While you've got the board pulled, make sure your standoffs are all correct. Inspect the back of the board for any signs of damage.
On the front, make sure that the PCH isn't getting too warm. There should be airflow over it. Check to make sure that the heatsink is secure and doesn't move at all - a heatsink failure could definitely cause this sort of issue, but is also quite out-of-the-ordinary. You can usually remove, clean, repaste, and reinstall a PCH heatsink. Use something like ArctiClean and Arctic Silver 5.
Clear the BIOS and reset to manufacturer defaults. Make sure that you only make necessary changes such as changing the SATA ports to AHCI mode (if that's needed). If it supports "hot swap" or "hot plug" mode also disable that. Because you're using a consumer grade board, these settings often come up "wrong" for FreeBSD/Linux, and sometimes some of these features don't really work correctly.
If there are power savings settings in the BIOS, try disabling them all. Also walk through all other BIOS settings with a mind towards "is this how it would be set for server use."
Make sure that all your drives are evenly spread across the power leads. If you've got five drives and three modular power leads that can handle drives, make sure you're going two drives on the first lead, two on the second, one and your fans on the third. Do not use SATA power Y's. Try to avoid Molex power Y's.
I disagree somewhat with
@Apollo above - if basic AHCI support was broken in FreeBSD, it is likely lots of people would be up in arms. However, because this is PC hardware, it is perfectly possible that the mainboard's implementation is somehow defective and needs some workaround for a quirk. That answer isn't pleasing in the modern era, however, as it is usually the PCH that is running the SATA, and that'll be an Intel chip, the same that works fine on many other boards. Not *impossible* but unlikely. FreeBSD and Linux used to have terrible issues supporting random discrete SATA chips in the pre-AHCI era. The advent of AHCI and boards using Intel-supplied silicon for it basically brought that horrible era to an end years ago.
Unfortunately, most home users aren't really outfitted to do deeper dives into these issues. Here in the shop we'd put the power on a scope and actually just *see* if there were brownouts. And/or we'd swap in a heavy PSU to *see*. We'd swap boards to a completely different model (and probably a Supermicro model) to see if that made a difference. We'd blow down the contacts with contact cleaner. We'd try new SATA cables and different drives. Etc. But all of this basically involves additional resources.
The other angle is that as someone who does server work professionally, there are things that you might have done that are just not obvious to me, or might even flabbergast me, but would have seemed just fine to you. We had someone who had neatly outfitted their rig with a bunch of SATA power Y's once, and wasn't really aware of what ampacity is. Likewise, as
@Apollo mentions, things like making sure standoffs are correct.
It's possible we aren't going to find the issue. One of the reasons we discourage consumer mainboards is because qualifying them for use with FreeBSD and FreeNAS would have to happen on a case-by-case basis. Manufacturers design these things to "work with Windows" and so the BIOS options tend to be all screwed up for use as a UNIX server. We find the Supermicro boards are generally well-suited for use as servers, because they are designed as server boards, and Supermicro knows what Linux, FreeBSD, ESXi, etc., are, and aims for these things to run on their platform. Supermicro actually made custom variants of their boards based on ESXi ethernet support years ago. But since you had a working system and now it isn't working, that's more of a head-scratcher.