© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
We found this exact same issue affecting several users with Unraid and kernel 5.15, they just needed to have VT-d enabled, it mostly affected HP servers of the same era, for example:
ProLiant MicroServer Gen8
ProLiant ML350p Gen8
ProLiant ML310e Gen8
ProLiant ML350 Gen9
ProLiant ML10 v2
but there was also a Lenovo X3100 M5, a Dell PowerEdge R710 and even a 6th gen i5 Asrock desktop board, so can't rule out any Intel based computer with VT-d enabled being affected sooner or later, but the HP servers listed were much more prone to the issue, we could sometimes trigger the bug in seconds, couple of minutes tops, by doing something i/o intensive, like for example starting a parity sync or check, problem started like above:
DMAR: ERROR: DMA PTE for vPFN xxxxxx already set (to xxxxxx not xxxxxx)
Then it started corrupting data, some times more severely than others, it happened with both filesystems typically used with Unraid, XFS and btrfs, though usually it was mostly found with btrfs since it started detecting data corruption errors, also btrfs is more vulnerable to memory corruption so it was more common to find a fatally damaged filesystem after some use.
Limetech found that changing iommu to pass-through mode instead of DMA translation mode fixed the problem, this can be done by changing this kernel option:
CONFIG_
Same as adding iommu=pt (or iommu.passtrough=1) to the kernel boot options.
They also found this document explaining the difference between the two modes:
https:/
Iommu pass-through mode bypasses the DMA translation, so it makes sense that any DMA remapping errors like the above stop happening, also note that we didn't find, at least as of today, any issues with PCIe device pass-through to a VM by using this mode, and according to the pdf above it's also being adopted as the new default by other Linux OSes.
P.S. the above mentioned commit (v5.15.6 commit 724ee060) doesn't help, we still saw this issue with kernel 5.15.46 if iommu DMA translation mode was enabled.