JorgeB

Might not be the same as this thread, did you upgrade to v6.10.0 or v6.10.2? Do you now what the NIC you have?

No corruption detected by btrfs so far, and when there's a problem it's usually quick to detect some, so if you ran other v6.10.x release for more than a day I would think it should be fine to enable vt-d, just monitor the log for the iommu error described in the post linked above, if you don't see that after a few hours use with vt-d enabled it's another indication you should be fine.

It's not a known affected model, but since most affected servers have been from HP it's difficult to say more for sure, if you have been running previous v6.10.x releases with vt-d enable for a few days and didn't notice any issues or errors logged you are most likely OK, diagnostics might also give a better idea.

I don't know if that's possible, but if it is, yes, I agree it would be better.

Doesn't make much sense, unless there also is one or more NICs that use the driver.

or check this post: https://forums.unraid.net/topic/124108-unraid-os-version-6102-available/?do=findComment&comment=1132815

What is the server hardware?

I wouldn't worry for now, no reason to believe they are related, different hardware and with the other issue those errors are constantly repeating.

The syslog starts over after every reboot, so not much to see, if it keeps crashing you should setup the syslog server and post that log after a crash.

Likely a NIC that uses the tg3 driver, see the release notes: https://forums.unraid.net/topic/124108-unraid-os-version-6102-available/ You can also post the diagnostics so we can see the hardware and recommend the best option.

Assuming you mean v6.10.2 disable vt-d: https://forums.unraid.net/topic/124108-unraid-os-version-6102-available/?do=findComment&comment=1132042

Yes, if you don't need hardware pass-through you can just disable IOMMU by adding 'intel_iommu=off to syslinux.cfg, and you can still use the VMs.

Please read the comments below, it uses the NIC but at least for now there's no evidence it's affected by the corruption issue, or did you see the error logged and/or suspect corruption?

6.10.2 also includes changes to the network rules, see if this helps: https://forums.unraid.net/topic/124108-unraid-os-version-6102-available/?do=findComment&comment=1132772

If you're seeing the above error you should disable vt-d, and it's a no brainer if you're not even using it.

You should be running 6.10.2 stable, not -rc3, also if you need help please post the diagnostics, also note that if you have NICs that use the tg3 driver they will be blacklisted, see the release notes for more info:

A small update on the possible tg3 related corruption issue, first I know it's a pain for some users updating and losing the NIC, especially if the server is remote, but because of this some users that are affected are now aware of it and what they need to do to avoid it, also note that there were unrelated changes made to the interface rules config, users that lose network because of bonding and other config issues is unrelated to the tg3 issue, like a couple of users from posts above. As for the affected servers, these are known to be affected if vt-d is enabled: HP ProLiant MicroServer Gen8 IBM/Lenovo x3100 M5 HP ProLiant ML350p Gen8 HP ProLiant ML310e Gen8 HP ProLiant DL20 Gen9 Also most likely affected: HP ProLiant ML350 Gen9 After a few hours of use in all of these, and if vt-d is enabled, you should start getting a similar error to this repeating in the log: May 23 18:58:31 unraidSERVER kernel: DMAR: ERROR: DMA PTE for vPFN 0xbdf79 already set (to bdf79003 not 19a5a1803) May 23 18:58:31 unraidSERVER kernel: ------------[ cut here ]------------ May 23 18:58:31 unraidSERVER kernel: WARNING: CPU: 19 PID: 47787 at drivers/iommu/intel/iommu.c:2408 __domain_mapping+0x2e5/0x390 This can be followed by some corruption, which can be more or less severe, possibly it can also non existent, but for now I wouldn't risk running a server if the above error appears, it should go away if vt-d is disabled. Because of the NIC being blacklisted there have been posts from several users running Dell servers with a NIC that uses the tg3 driver, as of now I didn't find any signs of the above error or corruption in those servers, it *might* be safe to continue to run those servers with vt-d on, especially if there are no signs of the above error in the logs. So does this mean tg3 driver is not the problem? I don't known, it's still might best guess, besides a bunch of Intel devices that I can't believe are the source of the problem or there would be a lot mores cases, I only found the tg3 NIC in common in all the affected servers , so it would be a big coincidence, but can't say for sure since I don't have the hardware to test, hopefully it will be made clearer in the coming days. @Thorstenfound the same exact issue reported for Ubuntu and ZFS, confirming as suspected that this is a general kernel issue, not an Unraid issue.

May 30 12:31:18 STOWER20 root: umount: /mnt/disk1: target is busy. Something is using disk1, maybe docker/appdata, see if the service stops manually before stopping the array.

You need to either disable vt-d or unblacklist the NIC, Dell servers appear to not have the corruption issue, so it *might* be OK to use the NIC, you can to that by doing this: https://forums.unraid.net/bug-reports/stable-releases/after-i-upgraded-to-6102-my-network-interfaces-dissappeared-r1956/?do=findComment&comment=19584

What is the NIC? Broadcom NICs that use the tg3 driver are blacklisted with v6.10.2 if vt-d is enable, in doubt post the diagnostics.

The Intel NIC is being loaded, to use the Broadcom NIC with v6.10.2 you should disable vt-d, more info in the release notes.

Array is not stopping, make sure nothing is using it, you might need to force a reboot, in that case make sure array autostart is disabled, and then try the commands again.

Symptoms point more to a power/connection problem, but if you already replace the cables it might be the drive, I would try once more, swap both cables with another drive, if the same one fails again it's likely a disk problem.

Like mentioned my experience with this particular model is that they work with Unraid basically as CMR drives, I've transferred more than 1TB continuously without any write slowdowns, they also work full speed during a parity sync or disk rebuild.

Settings -> Network Settings -> Interface rules -> Set that NIC as eth0, reboot is required after.