JorgeB

You can post the diagnostics after booting with one or the other, or both, that way we can at least see if the controllers are being detected and initialized correctly.

Problems with the docker image, apparently from running out of space, run a scrub on the docker image, or in doubt just delete and re-create it.

Enable the syslog server and post that after a crash.

Ahh, sorry, missed that part, update to v6.10.3-rc1 and you can have VT-d and the NICs.

Do you have another GPU (or if the CPU includes a GPU) you could try with? Also, does it start showing that right after booting Unraid or halfway through the boot?

Many thanks to @jmztaylorand @Monteromanfor helping test this new IOMMU mode, they are using different affected servers, one Lenovo X3100 and one HP Microserver G8, with both it was very easy to trigger the DMAR errors by starting a parity check, errors would start repeating after just a few seconds, e.g: With the Lenovo before this release: Jun 7 10:09:41 Tower kernel: md: recovery thread: check P ... Jun 7 10:09:44 Tower kernel: DMAR: ERROR: DMA PTE for vPFN 0xb0780 already set (to b0780003 not 17594b803) Jun 7 10:09:44 Tower kernel: ------------[ cut here ]------------ Jun 7 10:09:44 Tower kernel: WARNING: CPU: 4 PID: 6907 at drivers/iommu/intel/iommu.c:2336 __domain_mapping+0x2e3/0x362 With the HP: May 19 06:56:40 Tower kernel: md: recovery thread: check P ... May 19 06:56:56 Tower kernel: DMAR: ERROR: DMA PTE for vPFN 0xb5f80 already set (to b5f80003 not 1636f4803) May 19 06:56:56 Tower kernel: ------------[ cut here ]------------ May 19 06:56:56 Tower kernel: WARNING: CPU: 2 PID: 5826 at drivers/iommu/intel/iommu.c:2408 __domain_mapping+0x2e5/0x390 With the new release both ran a parity check for over 10 minutes with VT-d enabled and no signs of any errors, I'm confident this solves the DMAR/corruption issues for all affected platforms, as a bonus this IOMMU pass-through mode can apparently have better performance, some Linux distros have already switched to using it by default. Main kudos go to LT's @eschultz, he's the one that came up with the solution, also found the doc below with some more info about this mode for anyone interested: https://lenovopress.lenovo.com/lp1467.pdf P.S. this will also fix the bzimage checksum error many Dell server users were experiencing during boot after updating to v6.10.x, the fix for that was also using iommu=pt, and probably what saved some of those servers from experiencing the DMAR/corruption problem.

No, there's also the most free option, that one will write to the disk with most free space, but not usually recommended since it's the worse for performance, writes to parity will overlap when switching disks.

You can, just need a SAS expander, e.g.: MiniSAS cable from the HBA to the Expander, then with this example you could connect up to 32 devices, note that the PCIe slot is for power only, there are other models that don't require a PCIe slot, and can use for example a molex plug.

I would recommend deleting network-rules.cfg, and possibly also deleting or renaming network.cfg, then reboot to get back to defaults, then just reconfigure the network settings, all NICs should be correctly detected.

Sorry, not really sure about that.

I didn't, I said see if there's an updated Slackware package, I'm on a phone, can't really look for that now, if there isn't you'll need to wait for one, you can also look for help in the xfs mailing list.

Yes, because there's a problem with the filesystem on that disk that it can't fix, current xfsprogs is v5.14.2, you can see if there's an updated package fro slackware, like this: https://forums.unraid.net/topic/80162-disk-3-after-upgrade/#comment-745063

That looks related to the macvlan issue: See if this applies to you, if yes, switching to ipvlan should 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/

xfs_repair should always complete the repair without crashing, with more or less data loss, when it crashes like that it means there's a problem with it, cannot check now, can you confirm xfsprogs version inclued with v6.10 by typing: xfs_repair -V

Nothing really jumps out, please reboot and post new diags after array start.

It was a single disk filesystem, an array disk.

In case you missed it this is fixed on v6.10.3-rc1

Changed Status to Retest

In case you missed it this is fixed on v6.10.3-rc1

VMs should work qfter updating, but always good to make q backup of the vdisks, a relink is an option if they are on a btrfs or recent xfs filesystem.

You can mount any drive locally using the UD plugin, as long as it's formatted with a supported filesystem, like NTFS.

This is a xfs_repair problem, update to Unraid v6.10.2 or v6.10.3-rc1 and run it again, hopefully it's fixed in the newer xfsprogs.

If there's no data you want need there you just need to proceed as any new install, boot Unraid from a flash drive and assign the devices as you want.

Yes, I usually install the larger pair on A0+B0 then the smaller one on A1+B1, I remember reading somewhere that the larger capacity DIMMs should be installed first, but to be honest probably not much difference either way, important part is that each pair use both channels.

Make a backup of current config folder, recreate the flash drive manually or by using the USB tool, then restore the config folder.