# dmesg shows DMAR: DRHD: handling fault status reg 3

## Gentlenoob

Dear Gentooers,

whenever I issue 'fstrim -v /' (as recommended from time to time for SSD housekeeping) on my new HP laptop I reproducibly get (kernel 5.3.5-gentoo)

```

[92099.837655] DMAR: DRHD: handling fault status reg 3

[92099.837665] DMAR: [DMA Read] Request device [03:00.0] fault addr fffea000 [fault reason 06] PTE Read access is not set

[92099.841333] DMAR: DRHD: handling fault status reg 3

[92099.841344] DMAR: [DMA Read] Request device [03:00.0] fault addr ffbbf000 [fault reason 06] PTE Read access is not set

[92099.843685] DMAR: DRHD: handling fault status reg 3

[92099.843696] DMAR: [DMA Read] Request device [03:00.0] fault addr ffd4d000 [fault reason 06] PTE Read access is not set

[92099.846768] DMAR: DRHD: handling fault status reg 3

[92116.197545] dmar_fault: 410 callbacks suppressed

```

and some more of this kind. Otherwise my system seems to run without issues. lspci -k

```

00:00.0 Host bridge: Intel Corporation Device 3e34 (rev 0b)

        Subsystem: Hewlett-Packard Company Device 852e

        Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake)

        Subsystem: Hewlett-Packard Company UHD Graphics 620 (Whiskey Lake)

        Kernel driver in use: i915

        Kernel modules: i915

00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0b)

        Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem

        Kernel driver in use: proc_thermal

        Kernel modules: processor_thermal_device

00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model

        Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model

00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP Thermal Controller

        Kernel driver in use: intel_pch_thermal

        Kernel modules: intel_pch_thermal

00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP USB 3.1 xHCI Controller

        Kernel driver in use: xhci_hcd

        Kernel modules: xhci_pci

00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP Shared SRAM

00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)

        Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC]

        Kernel driver in use: iwlwifi

        Kernel modules: iwlwifi

00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP Serial IO I2C Controller

        Kernel driver in use: intel-lpss

        Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #1 (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP Serial IO I2C Controller

        Kernel driver in use: intel-lpss

        Kernel modules: intel_lpss_pci

00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP MEI Controller

        Kernel driver in use: mei_me

        Kernel modules: mei_me

00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 30)

        Subsystem: Hewlett-Packard Company 82801 Mobile SATA Controller [RAID mode]

        Kernel driver in use: ahci

        Kernel modules: ahci

00:1c.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #5 (rev f0)

        Kernel driver in use: pcieport

00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #9 (rev f0)

        Kernel driver in use: pcieport

00:1d.4 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #13 (rev f0)

        Kernel driver in use: pcieport

00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP LPC Controller

00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP High Definition Audio Controller

        Kernel driver in use: snd_hda_intel

        Kernel modules: snd_hda_intel

00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP SMBus Controller

        Kernel driver in use: i801_smbus

        Kernel modules: i2c_i801

00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)

        Subsystem: Hewlett-Packard Company Cannon Point-LP SPI Controller

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

        Subsystem: Hewlett-Packard Company RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

        Kernel driver in use: r8169

        Kernel modules: r8169

03:00.0 Non-Volatile memory controller: Intel Corporation SSDPEKNW020T8 [660p, 2TB] (rev 03)

        Subsystem: Intel Corporation SSDPEKNW020T8 [660p, 2TB]

        Kernel driver in use: nvme

```

Any hints? iommu may be one possible culprit, see e.g. https://forums.gentoo.org/viewtopic-p-8281896.html#8281896. As this is about 1y ago and I'm a bit wary of possibly hosing my SSD, I don't want to experiment too much and rather ask for your opinions beforehand. 

Thanks as always,

   Ralph

----------

## toralf

 *Gentlenoob wrote:*   

> whenever I issue 'fstrim -v /' (as recommended from time to time for SSD housekeeping) on my new HP laptop I reproducibly get (kernel 5.3.5-gentoo)
> 
> 

 IMO for a new laptop fstrim isn't needed any longer, the hardware + kernel should handle it well.

----------

## tholin

IOMMU errors like that are caused by either broken hardware, broken bios or buggy kernel.

In this case it seems to be a broken SM2263EN controllers in the 660p SSD. The people in this bugzilla has debugged the problem and come up with a patch but since kernel developers ignore bugzilla the upstream kernel developers are unaware of the problem.

https://bugzilla.kernel.org/show_bug.cgi?id=202665Last edited by tholin on Sat Oct 19, 2019 2:26 pm; edited 1 time in total

----------

## Gentlenoob

Ok, so I'll probably just wait for eventual kernel patch, the more as it might be a non-issue anyway. I should add that I consider my use-case not really heavyweight on SSD wear.

@Toralf (and others): Do you have some more pointers about fstrim not needed anymore on new hardware? Does it apply in particular for older file systems like ext4, which I'm actually using?

Cheers, Ralph

----------

## grumblebear

Thanks for the bugzilla link. I also had this problem with a HP SSD. To get rid of the annoying warning messages I enabled CONFIG_IOMMU_DEFAULT_PASSTHROUGH in my kernel, not really knowing if that has any negative effects.

----------

## Jaglover

Is there a good reason you have IOMMU enabled? I turn it always off because I do not use it. The argument about protecting against DMA attacks does not apply to me. The argument about added overhead does.

----------

## Gentlenoob

admittedly, no well thought out argument for IOMMU in my case. Just playing around with all kinds of kernel stuff during install, in particular enabling many INTEL_ options as I had initially some troubles with the Elan touchpad. Thanks for the hint, I may disable it if there's not much to gain.

Cheers, Ralph

----------

