[Bug 2168884] Re: ThinkPad X13 Gen 2 AMD (20XJ): ~11 second s2idle resume delay with AMD IOMMU enabled; delay disappears with amd_iommu=off

** Tags added: kernel-daily-bug -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2168884 Title: ThinkPad X13 Gen 2 AMD (20XJ): ~11 second s2idle resume delay with AMD IOMMU enabled; delay disappears with amd_iommu=off Status in linux package in Ubuntu: New Bug description: I am seeing a reproducible ~11 second delay when resuming a Lenovo ThinkPad X13 Gen 2 AMD, machine type 20XJ, from s2idle. After opening the lid, the display remains black for approximately 11 seconds before the system resumes normally. The issue disappears completely when booting once with: amd_iommu=off With AMD IOMMU disabled, resume is effectively immediate. The closely related ThinkPad X13 Gen 2 AMD machine type 20XH is currently present in the AMD PMC firmware bug quirk table, while 20XJ is not. The existing quirk is documented as working around a platform firmware issue where an SMI handler during the NVMe D3→D0 transition can cause large resume delays while IOMMU translation is enabled. This appears consistent with the behavior observed on this 20XJ system. GitHub Hardware System: Lenovo ThinkPad X13 Gen 2 AMD Machine type: 20XJ CPU: AMD Ryzen 5 PRO 5650U with Radeon Graphics RAM: 16 GB NVMe: Samsung MZVLB512HBJQ-000L7 The system also contains a Quectel EM120R-GL LTE modem, but disabling Wireless WAN completely in UEFI had no effect on the resume delay. Firmware BIOS version: R1NET67W (1.37) BIOS date: 04/16/2026 Software Kernel: 7.0.0-34-generic linux-firmware: 20260319.git217ca6e4.1ubuntu Suspend mode: $ cat /sys/power/mem_sleep [s2idle] The firmware exposes only s2idle on this system. Steps to reproduce 1. Boot normally with AMD IOMMU enabled. 2. Log into the desktop. 3. Suspend the laptop normally by closing the lid or invoking suspend. 4. Wait for the system to enter s2idle. 5. Open the lid. 6. Measure the time before the display becomes active. Actual result The screen remains black for approximately: 11+ seconds before the system becomes usable. The problem is reproducible across repeated suspend/resume cycles. Expected result Resume should occur within approximately 1–2 seconds, as it does when AMD IOMMU is disabled. Important A/B test I edited the GRUB kernel command line for one boot only and appended: amd_iommu=off No other relevant configuration was changed. Result: Normal boot / IOMMU enabled: ~11 seconds black screen after opening lid amd_iommu=off: resume immediately / delay disappears This result is reproducible and strongly suggests that the delay depends on AMD IOMMU being enabled. WWAN test Because this system contains a Quectel EM120R-GL LTE modem using mhi_pci_generic, I also tested whether the WWAN device was responsible. Detected device: 04:00.0 Unassigned class [ff00]: Quectel Wireless Solutions Co., Ltd. EM120R-GL LTE Modem [1eac:1001] Kernel driver in use: mhi_pci_generic Kernel modules: mhi_pci_generic ModemManager detects: [Quectel] EM120R_GL I disabled Wireless WAN completely in ThinkPad UEFI: Security -> I/O Port Access -> Wireless WAN: Off The ~11 second resume delay remained unchanged. Therefore the WWAN modem does not appear to be responsible for this issue. Relevant kernel observations The system logs contain recurring AMD display firmware diagnostics: amdgpu 0000:05:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data However, once the visible kernel resume sequence begins, the AMD GPU itself resumes quickly: amdgpu 0000:05:00.0: SMU is resuming... amdgpu 0000:05:00.0: SMU is resumed successfully! and PM: suspend exit follows shortly afterwards. The logs also show: nvme nvme0: D3 entry latency set to 8 seconds I understand that this value is a power-management latency value and is not by itself evidence of an 8-second measured stall. The long user-visible delay appears to occur before the normal device resume sequence becomes visible in the kernel log, which would be consistent with a firmware/SMI-level delay. AMD PMC quirk observation Current upstream drivers/platform/x86/amd/pmc/pmc-quirks.c contains an entry for: X13 Gen2 AMD DMI_PRODUCT_NAME = "20XH" using: quirk_s2idle_spurious_8042 but I do not see a corresponding 20XJ entry. GitHub The same source describes the relevant workaround as applying to systems where a firmware SMI handler during the NVMe D3→D0 transition can cause large resume delays when IOMMU translation is enabled. GitHub My affected machine is: ThinkPad X13 Gen 2 AMD DMI product name: 20XJ This makes me suspect that 20XJ may require the same quirk currently applied to 20XH. Additional observation Searching the boot log for: Using s2idle quirk produces no output on this machine. For example: sudo journalctl -b -k | grep -i "Using s2idle quirk" returns nothing. The AMD PMC driver prints such a message when an applicable s2idle_bug_mmio quirk is selected. GitHub Proposed investigation Could you please confirm whether ThinkPad X13 Gen 2 AMD machine type 20XJ should use the same AMD PMC firmware workaround as 20XH? A likely DMI addition would conceptually correspond to the existing X13 Gen 2 AMD entry, but match: DMI_PRODUCT_NAME, "20XJ" I have not applied a custom kernel patch yet, so I have not independently verified the quirk itself on 20XJ. What I have verified is: 20XJ + normal IOMMU configuration -> ~11 s resume delay 20XJ + WWAN disabled -> ~11 s resume delay 20XJ + amd_iommu=off -> immediate resume ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: linux-image-7.0.0-34-generic 7.0.0-34.34 ProcVersionSignature: Ubuntu 7.0.0-34.34-generic 7.0.14 Uname: Linux 7.0.0-34-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Sep 29 20:08:18 2026 InstallationDate: Installed on 2026-09-23 (6 days ago) InstallationMedia: Ubuntu 26.04.1 LTS "Resolute Raccoon" - Release amd64 (20260826) MachineType: LENOVO 20XJS1XM00 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-7.0.0-34-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/16/2026 dmi.bios.release: 1.37 dmi.bios.vendor: LENOVO dmi.bios.version: R1NET67W (1.37) dmi.board.asset.tag: Not Available dmi.board.name: 20XJS1XM00 dmi.board.vendor: LENOVO dmi.board.version: SDK0T76538 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.37 dmi.modalias: dmi:bvnLENOVO:bvrR1NET67W(1.37):bd04/16/2026:br1.37:efr1.37:svnLENOVO:pn20XJS1XM00:pvrThinkPadX13Gen2a:rvnLENOVO:rn20XJS1XM00:rvrSDK0T76538WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20XJ_BU_Think_FM_ThinkPadX13Gen2a:pfaThinkPadX13Gen2a: dmi.product.family: ThinkPad X13 Gen 2a dmi.product.name: 20XJS1XM00 dmi.product.sku: LENOVO_MT_20XJ_BU_Think_FM_ThinkPad X13 Gen 2a dmi.product.version: ThinkPad X13 Gen 2a dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2168884/+subscriptions