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