Hello everyone,
I would like to report a regression regarding PCI Passthrough on the Ugreen DXP6800 Pro hardware. This issue caused downtime and forced me to recover corrupted ZFS datasets, so I hope this report helps others avoid the same situation.
About me:
I am a software developer and hobbyist/homelab enthusiast, but I am not a professional senior Linux administrator. I have drafted this post with the assistance of Gemini to ensure the technical details are presented as clearly and efficiently as possible. Feel free to ask questions and I try to answer as good as possible.
System Environment:
Identified SATA Controllers:
The Problem:
After updating to kernel 6.17.13-2-pve, the system became unstable under I/O load (e.g., large SMB transfers or ZFS scrubs). The guest ZFS pool would report massive checksum errors and enter a
The Proxmox host logged recurring DMAR faults during these events:
The Troubleshooting Journey:
Initially, I suspected hardware failure or RAM issues. However, after extensive testing (including Memtest and physical disk checks), the hardware proved healthy. The ZFS pool errors were "ghost errors" caused by the IOMMU blocking legitimate DMA writes to the VM's memory space, which ZFS interpreted as data corruption.
The Solution (Regression Proof):
The issue is resolved by pinning the kernel to version 6.17.9-1-pve.
Conclusion:
It seems that a change introduced between kernel versions .9 and .13 in the 6.17 series affects how PTE (Page Table Entry) write permissions are handled or enforced for these specific controllers on the Alder Lake-P platform.
I will stay on 6.17.9-1-pve for now. Is this a known regression, or are there specific IOMMU quirks required for the ASM1164 or Intel 51d3 controllers in newer builds?
Cheers
Kai
I would like to report a regression regarding PCI Passthrough on the Ugreen DXP6800 Pro hardware. This issue caused downtime and forced me to recover corrupted ZFS datasets, so I hope this report helps others avoid the same situation.
About me:
I am a software developer and hobbyist/homelab enthusiast, but I am not a professional senior Linux administrator. I have drafted this post with the assistance of Gemini to ensure the technical details are presented as clearly and efficiently as possible. Feel free to ask questions and I try to answer as good as possible.
System Environment:
- Hardware: Ugreen DXP6800 Pro (Intel Core i5-1235U / Alder Lake-P)
- RAM: 64GB DDR5 (Verified with 24h Memtest86+, 0 errors)
- Host OS: Proxmox VE 9.1.6
- VM: TrueNAS SCALE (SATA Controllers passed through via VFIO)
Identified SATA Controllers:
Code:
00:17.0 SATA controller [0106]: Intel Corporation Alder Lake-P SATA AHCI Controller [8086:51d3] (rev 01)
5e:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1164 Serial ATA AHCI Controller [1b21:1164] (rev 02)The Problem:
After updating to kernel 6.17.13-2-pve, the system became unstable under I/O load (e.g., large SMB transfers or ZFS scrubs). The guest ZFS pool would report massive checksum errors and enter a
SUSPENDED state almost immediately.The Proxmox host logged recurring DMAR faults during these events:
Code:
DMAR: [DMA Write NO_PASID] Request device [5e:00.0] fault addr 0x4c020000 [fault reason 0x05] PTE Write access is not set
DMAR: [DMA Write NO_PASID] Request device [00:17.0] fault addr 0x4c68b000 [fault reason 0x05] PTE Write access is not setThe Troubleshooting Journey:
Initially, I suspected hardware failure or RAM issues. However, after extensive testing (including Memtest and physical disk checks), the hardware proved healthy. The ZFS pool errors were "ghost errors" caused by the IOMMU blocking legitimate DMA writes to the VM's memory space, which ZFS interpreted as data corruption.
The Solution (Regression Proof):
The issue is resolved by pinning the kernel to version 6.17.9-1-pve.
- 6.17.13-2-pve: Fails consistently under I/O load.
- 6.17.9-1-pve: Stable (for days now). I have since transferred over "a lot" of data (TBytes) without any further DMAR faults or ZFS errors. Also a Scrub was successful (failed with newer Kernel version)
Conclusion:
It seems that a change introduced between kernel versions .9 and .13 in the 6.17 series affects how PTE (Page Table Entry) write permissions are handled or enforced for these specific controllers on the Alder Lake-P platform.
I will stay on 6.17.9-1-pve for now. Is this a known regression, or are there specific IOMMU quirks required for the ASM1164 or Intel 51d3 controllers in newer builds?
Cheers
Kai
Last edited: