JorgeB

Crashing looks more hardware related, you can try running memtest if you haven't yet, can also try upgrading to v6.10-rc8 mostly to rule out any kernel compatibility issue.

We can 't see why the disks got disable because of the reboots but they look healthy, and two disks getting disable at the same time is seldom a device problem, since the emulate disks are mounting and assuming contents look correct you can rebuild on top:
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
 

May 3 05:13:01 smashboogie kernel: macvlan_broadcast+0x116/0x144 [macvlan] May 3 05:13:01 smashboogie kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan]  
 
Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Are you doing this?
 
https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&comment=557606
 

blkdiscard /dev/sdX or
blkdiscard -f /dev/sdX depending on the Unraid version.

You can download v6.9.2 and replace all the bz* files on the flash, then reboot.

Those are very old, see the link above to update to 20.00.07.00

That's a good place to start based on the corruption found by btrfs.

First one looks mcvaln related, 2nd one NIC related, but possibly a consequence of the first crash, see below:
 
See if this applies to you, if yes, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.:
 
https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
 
See also here:
https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

If you don't need it try disabling IOMMU, error appears to be rated to that with the LSI HBA, since it's a microserver I assume you can't install the HBA in a different PCIe slot, if you can also try that.

It does, check the board BIOS for the SEL (system event log), there might be more info there, including the affected DIMM.

Nope, it should wake up after pressing any key, you can disable console blanking by adding
setterm -blank 0 to /boot/config/go and rebooting.

Docker image is showing a very low transid, this means it was recently created, like today or yesterday tops, assuming appdata is still there you can just re-add the dockers using CA, or if you think there could be another image somewhere else you can search for one:
 
find /mnt -name docker.img  

NVMe is dropping offline:
 
Sep 5 13:38:54 Unraid kernel: nvme nvme0: I/O 771 QID 7 timeout, aborting Sep 5 13:38:54 Unraid kernel: nvme nvme0: I/O 772 QID 7 timeout, aborting Sep 5 13:38:54 Unraid kernel: nvme nvme0: I/O 773 QID 7 timeout, aborting Sep 5 13:38:54 Unraid kernel: nvme nvme0: I/O 234 QID 1 timeout, aborting Sep 5 13:39:24 Unraid kernel: nvme nvme0: I/O 771 QID 7 timeout, reset controller Sep 5 13:39:54 Unraid kernel: nvme nvme0: I/O 0 QID 0 timeout, reset controller Sep 5 13:40:57 Unraid kernel: nvme nvme0: Device not ready; aborting reset Sep 5 13:40:57 Unraid kernel: nvme nvme0: Abort status: 0x7 ### [PREVIOUS LINE REPEATED 3 TIMES] ### Sep 5 13:41:27 Unraid kernel: nvme nvme0: Device not ready; aborting reset Sep 5 13:41:27 Unraid kernel: nvme nvme0: Removing after probe failure status: -19 Sep 5 13:41:58 Unraid kernel: nvme nvme0: Device not ready; aborting reset  
This sometimes helps, some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append" and before "initrd=/bzroot"
 
nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference, if it doesn't you can try the latest beta, newer kernel might also help, if not try a different model NVMe device if possible.

It can be, it could even be neither, it could be for example a PSU problem, but since there are also CRC errors and those can basically only be from the controller, cables or backplane and the other disk issues are likely related it should be one of them, backplane more likely but HBA is also a possibility, especially if it's a Chinese fake, unfortunately no way of knowing for sure until you rule one of them out, either by using a different HBA or connecting the disks directly bypassing the backplane (or using a different one).

Cache filesystem is corrupt, you should backup and re-format.

May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 067b1393-440b-497e-b688-fb11e9c6611d devid 3 transid 645077 /dev/nvme3n1p1 scanned by udevd (2760) May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 067b1393-440b-497e-b688-fb11e9c6611d devid 2 transid 291831 /dev/nvme0n1p1 scanned by udevd (2792)  
As you can see the transid of one of the devices is way off, it should be the same for all pool members, note the other pool below:
 
May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 565f4d7d-1b62-4a67-9414-ac108e2553f3 devid 3 transid 31253 /dev/nvme1n1p1 scanned by udevd (2741) May 8 21:10:17 ThreadRipper19 kernel: BTRFS: device fsid 565f4d7d-1b62-4a67-9414-ac108e2553f3 devid 2 transid 31253 /dev/nvme2n1p1 scanned by udevd (2727)  
The difference is so large that it couldn't happen if a device lost a few writes, so likely some corruption happened here, also note that Ryzen with overclocked RAM like you have is known to in some cases corrupt data, so suggest fixing that.
 
You can first try restoring the superblock from backup to see if it helps, do it both both pool devices:

 
btrfs-select-super -s 1 /dev/nvme3n1p1 btrfs-select-super -s 1 /dev/nvme0n1p1  
Then reboot and post new diags.

If it's still slow also a good idea to run a test with the diskspeed docker to make sure all disks are performing normally.

Them I would suggest trying with a new flash drive config, you don't even need a key, just to see if you can access the server that way, if yes it's a problem with the old config, and you can then reconfigure the server or try copying a few config files to test and identify the culprit.

Free space with an odd number of devices won't be correct, it's a btrfs issue, but the total space is usable and the free space reported will get better as you fill the pool.

Make sure nothing is accessing the disk during the diskspeed test (or parity check), and if it's still slow it's the disk.

Problem with the onboard SATA controller, quite common with some Ryzen boards, BIOS update might help or use an add-on controller.
 
You need to reboot to see actual array status, there might be a disabled disk.

Not while it's still assigned to the array, you can unassign it, start the array without it then format the device directly (not the emulated disk) with UD or using the CLI.

Click on settings in front of the disk you want to enable that:
 

 
Then enable "Share"
 
P.S. next time please use the existing plugin support thread.