| 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
| ||
|
Message-ID: <f1658459-1b77-41b1-9e58-99c16a83e1d1@molgen.mpg.de>
Date: Mon, 22 Jan 2024 13:16:25 +0100
From: Paul Menzel <pmenzel@...gen.mpg.de>
To: "Christian A. Ehrhardt" <lk@...e.de>
Cc: Jörg Rödel <joro@...tes.org>,
Will Deacon <will@...nel.org>, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, Mike Jones <mike@...nes.io>,
linux-i2c@...r.kernel.org, linux-acpi@...r.kernel.org,
Hans de Goede <hdegoede@...hat.com>
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`
[Cc: +linux-i2c, +linux-acpi, +Hans, cf original message [1]]
Dear Christian,
Thank you for your reply.
Am 19.01.24 um 18:57 schrieb Christian A. Ehrhardt:
> 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.
I disassembled it with `iasl -d` (attached), and there are indeed two
devices:
[058h 0088 001h] Device Scope Type : 03 [IOAPIC Device]
[059h 0089 001h] Entry Length : 08
[05Ah 0090 002h] Reserved : 0000
[05Ch 0092 001h] Enumeration ID : 02
[05Dh 0093 001h] PCI Bus Number : F0
[05Eh 0094 002h] PCI Path : 1F,00
[060h 0096 001h] Device Scope Type : 04 [Message-capable
HPET Device]
[061h 0097 001h] Entry Length : 08
[062h 0098 002h] Reserved : 0000
[064h 0100 001h] Enumeration ID : 00
[065h 0101 001h] PCI Bus Number : 00
[066h 0102 002h] PCI Path : 1F,00
$ grep Name DMAR.dsl
* Format: [HexOffset DecimalOffset ByteLength] FieldName :
FieldValue (in hex)
[068h 0104 001h] Device Scope Type : 05 [Namespace Device]
[070h 0112 001h] Device Scope Type : 05 [Namespace Device]
[0B8h 0184 002h] Subtable Type : 0004 [ACPI Namespace
Device Declaration]
[0C0h 0192 00Fh] Device Name : "\_SB.PCI0.I2C0"
[0D4h 0212 002h] Subtable Type : 0004 [ACPI Namespace
Device Declaration]
[0DCh 0220 00Fh] Device Name : "\_SB.PCI0.I2C1"
> Your dmesg shows two ANDD records for your I2C controllers,
> so somehow the I2C controller is sending interrupts 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.
I am adding the Linux I2C and ACPI folks. Maybe they have an idea.
Kind regards,
Paul
[1]:
https://lore.kernel.org/all/5517f76a-94ad-452c-bae6-34ecc0ec4831@molgen.mpg.de/
View attachment "DMAR.dsl" of type "text/x-dsl" (6577 bytes)
Powered by blists - more mailing lists