JorgeB

Not sure, though have experience with those controllers, we usually recommend LSI HBAs.

This is usually board or NVMe device related, or both together.

Feb 17 23:35:45 Rawpower kernel: BTRFS: device fsid f3246c47-c90d-4662-aef8-0197be2da3f7 devid 6 transid 162676 /dev/nvme0n1p1 scanned by udevd (7431) Feb 17 23:35:45 Rawpower kernel: BTRFS: device fsid f3246c47-c90d-4662-aef8-0197be2da3f7 devid 7 transid 142467 /dev/nvme1n1p1 scanned by udevd (7431) Transid is way off for one of the devices, they should be the same for all members of the same pool, besides that the superblock also appears to be damaged: Feb 17 23:37:21 Rawpower kernel: BTRFS error (device nvme0n1p1): super_num_devices 1 mismatch with num_devices 1 found here There are some recovery options here you can try but not sure they will work with this kind of damage: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=543490

The ATA errors are usually caused by issues with the power or SATA connections, both go through the backplane.

Yep, that was the problem.

Nothing jumps out in the hardware used, enable the syslog server and post that after a crash.

Disk6 is failing, since parity isn't valid you can do a standard rebuild, you can try to manually copy everything you can from that disk or use for example ddrescue.

Enable the syslog server and post that after a crash.

Diags is showing issues with two devices at the same time, so most likely some backplane related issue, or the SATA controller.

Reboot.

Parity check is for the array, you can run a scrub on the pool.

Since it's happening with all the disks connected to the Intel SATA controller there could be a power/connection problem, or the board/controller is going bad, the former is much more likely.

Feb 15 18:04:11 TheSentinel kernel: nvme nvme0: pci function 0000:04:00.0 Feb 15 18:04:11 TheSentinel kernel: nvme 0000:04:00.0: can't change power state from D3hot to D0 (config space inaccessible) Feb 15 18:04:11 TheSentinel kernel: nvme nvme0: Removing after probe failure status: -19 Device is failing to initialize, don't think there's much you can do other than trying a different NVMe device (or a different board), you can also try v6.10-rc2 but doubt that it would help.

Nothing about the crash in the syslog, this usually points to a hardware issue, and not saying that is the problem but RAM is still overclocked.

Yes, just delete and re-create the docker image, can't help with the VM issues.

Device sdg was successfully removed from the pool, any mentions of it should stop once you reboot, possibly after an array re-start.

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/

Could be this: https://forums.unraid.net/bug-reports/prereleases/69x-610x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-r1674/?do=getNewComment&d=2&id=1674

This is a different problem, post new diags. See if there's an option to disable the Bluetooth module in the BIOS.

You can still use the data in all the other data drives, and depending on how bad the data drive failed you might still be able to recover some/most data there with for example ddrescue.

On main click on the disk, then scroll down to the self-test section and click on extended SMART test, make sure disk spin down is disable for that disk at least.

I don't like to keep bumping threads, also did that a couple of times for this pool bug which is a basic functionality and didn't help much, though last I heard it's finally being looked at.

Yes, it pauses for a few seconds (couple minutes max) or the format would take a long time, and disk will be available after the format is done.

It's logged as a disk problem, you can run an extended SMART test to confirm.

Yes.