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

[Baolu Lu <baolu.lu@linux.intel.com>]

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 
> (debian-kernel@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

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/20260227080638.208693-1-lkml@antheas.dev/

Could you please test if this patch helps? It has already been merged
into the iommu subsystem tree.

Thanks,
baolu