Linux error `[DMA Write NO_PASID] Request device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set`
Paul Menzel
pmenzel at molgen.mpg.de
Wed Mar 18 05:55:34 PDT 2026
Dear Baolu,
Am 18.03.26 um 07:42 schrieb Baolu Lu:
> On 3/16/26 22:54, Paul Menzel wrote:
>>>> On the Intel Kaby Lake laptop Dell XPS 13 9360, Linux logs the error
>>>> below:
>>>>
>>>> [17959.189315] ACPI: EC: event unblocked
>>>> [17959.197876] DMAR: DRHD: handling fault status reg 2
>>>> [17959.197882] DMAR: [DMA Write NO_PASID] Request device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set
>>>> [17959.198366] DMAR: DRHD: handling fault status reg 2
>>>> [17959.198369] DMAR: [DMA Write NO_PASID] Request device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set
>>>> [17959.198923] DMAR: DRHD: handling fault status reg 2
>>>> [17959.201477] nvme nvme0: 4/0/0 default/read/poll queues
>>>>
>>>> 3c:00.0 is the NVMe controller/device.
>>>>
>>>> $ lspci -nn -s 3c:00.0
>>>> 3c:00.0 Non-Volatile memory controller [0108]: SK hynix PC300 NVMe Solid State Drive 512GB [1c5c:1284]
>>>>
>>>> This seems to happen only *sometimes* when resuming from ACPI S3.
>>>>
>>>> To my knowledge, this is *not* a new problem. Please find the log
>>>> messages attached. (Ignore the other DMAR error for now.)
>>>
>>> These IOMMU DMA faults are triggered when the NVMe controller attempts
>>> DMA writes to system memory address 0x0. The IOMMU hardware blocked
>>> these accesses because the system software has not granted the device
>>> permission to write to this specific address. It's unlikely a bug or
>>> problem in the iommu driver as far as I can see.
>>
>> I am seeing the same issue on a Dell XPS 15 7590 with Intel NVMe
>> controller:
>>
>> $ lspci -nn -s 3d:00.0
>> 3d:00.0 Non-Volatile memory controller [0108]: Intel Corporation SSD DC P4101/Pro 7600p/760p/E 6100p Series [8086:f1a6] (rev 03)
>>
>> Logs from Debian’s Linux 6.19.8:
>
> Did you see this warning with the v6.18 kernel or earlier?
Yes, I did see it with earlier Linux versions. For the Dell XPS 13 9360
with SK hynix controller I found logs with Linux 6.16:
Okt 14 08:10:02 abreu kernel: Linux version 6.16.11+deb14-amd64
(debian-kernel at lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian
14.3.0-8) 14.3.0, GNU ld (GNU Binutils for Debian) 2.45) #1 SMP
PREEMPT_DYNAMIC Debian 6.16.11-1 (2025-10-07)
[…]
Okt 15 21:02:49 abreu kernel: DMAR: DRHD: handling fault status reg 2
Okt 15 21:02:49 abreu kernel: DMAR: [DMA Write NO_PASID] Request
device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is
not set
Okt 15 21:02:49 abreu kernel: DMAR: DRHD: handling fault status reg 2
Okt 15 21:02:49 abreu kernel: DMAR: [DMA Write NO_PASID] Request
device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is
not set
Okt 15 21:02:49 abreu kernel: DMAR: DRHD: handling fault status reg 2
Okt 15 21:02:49 abreu kernel: nvme nvme0: 4/0/0 default/read/poll
queues
>> [ 726.138732] DMAR: DRHD: handling fault status reg 3
>> [ 726.138736] DMAR: [DMA Read NO_PASID] Request device [3d:00.0] fault addr 0xffffd000 [fault reason 0x06] PTE Read access is not set
>> [ 726.141470] nvme nvme0: 12/0/0 default/read/poll queue
Just for the record, as I missed it, that it’s fault reason 0x05 (PTE
*Write* access) on the Dell XPS 13 9360, and 0x06 (PTE *Read* access) on
the Dell XPS 15 7590.
>> It’d be great if this could be fixed.
Kind regards,
Paul
PS: The archive of Linux messages of the project Hardware for Linux [2]
contains quite a lot of logs, but most of them are from systems, where
no suspend/resume cycle was performed.
[1]: https://github.com/linuxhw/Dmesg
[2]: https://linux-hardware.org/
More information about the Linux-nvme
mailing list