linux-kernel - Re: Dell XPS 13 9360: DMAR errors `DRHD: handling fault status reg 2` and `[INTR-REMAP] Request device [f0:1f.0] fault index 0x0`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zaq4Gv2SWhd12Lx0@cae.in-ulm.de>
Date: Fri, 19 Jan 2024 18:57:46 +0100
From: "Christian A. Ehrhardt" <lk@...e.de>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Jörg Rödel <joro@...tes.org>,
	Will Deacon <will@...nel.org>, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: Dell XPS 13 9360: DMAR errors `DRHD: handling fault status reg
 2` and `[INTR-REMAP] Request device [f0:1f.0] fault index 0x0`


Hi Paul,

On Fri, Jan 19, 2024 at 01:59:29PM +0100, Paul Menzel wrote:
> On a Dell XPS 13 9360 Linux 6.6.8, 6.6.11 and 6.7 (and earlier versions) log
> the lines below when resuming from ACPI S3 (deep):
> 
>     [    0.000000] Linux version 6.7-amd64 (debian-kernel@...ts.debian.org)
> (x86_64-linux-gnu-gcc-13 (Debian 13.2.0-9) 13.2.0, GNU ld (GNU Binutils for
> Debian) 2.41.50.20231227) #1 SMP PREEMPT_DYNAMIC Debian 6.7-1~exp1
> (2024-01-08)
>     [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.7-amd64
> root=UUID=32e29882-d94d-4a92-9ee4-4d03002bfa29 ro quiet pci=noaer
> mem_sleep_default=deep log_buf_len=8M
>     […]
>     [    0.000000] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
>     […]
>     [   99.711230] PM: suspend entry (deep)
>     […]
>     [   99.722101] printk: Suspending console(s) (use no_console_suspend to
> debug)
>     [  100.285178] ACPI: EC: interrupt blocked
>     [  100.319908] ACPI: PM: Preparing to enter system sleep state S3
>     [  100.331793] ACPI: EC: event blocked
>     [  100.331798] ACPI: EC: EC stopped
>     [  100.331800] ACPI: PM: Saving platform NVS memory
>     [  100.335224] Disabling non-boot CPUs ...
>     [  100.337412] smpboot: CPU 1 is now offline
>     [  100.341065] smpboot: CPU 2 is now offline
>     [  100.346441] smpboot: CPU 3 is now offline
>     [  100.353086] ACPI: PM: Low-level resume complete
>     [  100.353129] ACPI: EC: EC started
>     [  100.353129] ACPI: PM: Restoring platform NVS memory
>     [  100.355219] Enabling non-boot CPUs ...
>     [  100.355244] smpboot: Booting Node 0 Processor 1 APIC 0x2
>     [  100.355954] CPU1 is up
>     [  100.355972] smpboot: Booting Node 0 Processor 2 APIC 0x1
>     [  100.356698] CPU2 is up
>     [  100.356716] smpboot: Booting Node 0 Processor 3 APIC 0x3
>     [  100.357371] CPU3 is up
>     [  100.360217] ACPI: PM: Waking up from system sleep state S3
>     [  100.668380] ACPI: EC: interrupt unblocked
>     [  100.668598] pcieport 0000:00:1c.0: Intel SPT PCH root port ACS
> workaround enabled
>     [  100.668606] pcieport 0000:00:1c.4: Intel SPT PCH root port ACS
> workaround enabled
>     [  100.668643] pcieport 0000:00:1d.0: Intel SPT PCH root port ACS
> workaround enabled
>     [  100.690996] DMAR: DRHD: handling fault status reg 2
>     [  100.691001] DMAR: [INTR-REMAP] Request device [f0:1f.0] fault index
> 0x0 [fault reason 0x25] Blocked a compatibility format interrupt request
> 
> But I am unable to find the device f0:1f.0:

This is probably an ACPI enumerated device. These are platform
devices that pose as a PCI device for the purpose of interrupt
remapping but do not enumerate via PCI. The PCI ID assigned to
these hidden devices is enumerated via ANDD entries in the
DMAR table. You can decode this table with from
/sys/firmware/acpi/tables/DMAR with iasl to verify.

Your dmesg shows two ANDD records for your I2C controllers,
so somehwo the I2C controller is sending interrups that DMAR
doesn't like (probably because the I2C controller is not yet
resumed properly).

Thus my guess is that this is an issue with the suspend/resume hooks
of the I2C controllers not with the IOMMU.

      regards   Christian