Re: Linux error `[DMA Write NO_PASID] Request device [3c:00.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set`

Dear Baolu,


Thank you for your reply, and sorry for the late response.

Am 19.03.26 um 07:06 schrieb Baolu Lu:
> On 3/18/26 20:55, Paul Menzel wrote:
>>
>> 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 ([email protected]) (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
> 
> The error occurs when the NVMe controller attempts to access system
> memory using IOVA 0. The iommu subsystem reserves IOVA 0 and treats it
> as an invalid address; therefore, the Linux driver is unlikely to
> program a device with IOVA 0 for DMA.
> 
> An exception is reserved memory used by firmware, where the regions are
> identity-mapped by the iommu core during the probe process. There was a
> recent fix addressing an issue with identity mapping at address 0:
> 
> https://lore.kernel.org/linux-iommu/[email protected]/
> 
> Could you please test if this patch helps? It has already been merged
> into the iommu subsystem tree.

The patch entered Linux v7.0-rc5, and I am seeing this with Debian’s 
7.2-rc7 (and before), so unfortunately it did *not* help.

The problem is, I am only able to reproduce it with the packaged Debian 
Linux kernel, and not the one I build myself. Additionally the bug is 
not manifesting every boot, so I also still have not a real reproducer.


Kind regards,

Paul