I've seen reports of ath12k causing similar issues before. There is already a kernel update waiting in -proposed so it might be worth checking if that fixes it.
You can enable it by adding questing-proposed to /etc/apt/sources.list.d/ubuntu.sources at: Suites: questing questing-updates questing-backports questing-proposed and adding a file /etc/apt/preferences.d/proposed with: ``` Package: * Pin: release a=questing-proposed Pin-Priority: 400 Package: linux-* Pin: release a=questing-proposed Pin-Priority: 1000 ``` The second part makes sure it only fetches the kernel from the proposed pocket instead of all packages. With this apt update && apt upgrade should offer an upgrade to 6.17.0-6 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2127013 Title: [BUG] Lenovo ThinkPad T14s Gen 6 (Snapdragon X Elite): immediate resume / suspend abort (s2idle & deep) Status in linux package in Ubuntu: New Bug description: (NOTE: This was AI-assisted for conciseness, but human reviewed and edited) ### Summary **System:** Lenovo ThinkPad T14s Gen 6 (ARM64, Snapdragon X Elite X1E80100) **OS:** Ubuntu 25.04 (kernel 6.14.x) **Issue:** System immediately resumes from suspend (both `s2idle` and `deep`) --- ### Description When entering suspend (`systemctl suspend`), the laptop begins the suspend sequence but immediately resumes — typically within one second. This happens both when suspending manually and when closing the lid. Note this wake happens before I reopen the lid (in all tests I wait a least 20 seconds before re-opening). No crash, kernel panic, or watchdog reset occurs; the system simply aborts suspend before reaching a low-power state. --- ### Observed behavior - `PM: suspend entry (s2idle|deep)` → CPUs disabled → CPUs re-enabled → `PM: suspend exit` - No “Wakeup: device …” messages appear. - No `event_count` increases in `/sys/kernel/debug/wakeup_sources` — only `last_change` timestamps change. - `last_change` increments for: - `0-003a` (I²C device, likely lid or Hall sensor) - `gpio-keys` (platform driver handling lid and power buttons) This indicates the kernel aborts suspend during entry due to a wake- capable input toggling state, not because of a true wake event. --- ### Tests performed | Test | Result | |------|---------| | Unloaded `ath12k`, `mhi_pci_generic`, `qrtr_mhi`, and `mhi` (Wi-Fi stack) | Same result | | Disabled I²C devices `1-0015`, `1-003a` | Same result | | Disabled lid GPIO wake (`gpio-keys`) | Same result | | `pm_test` (`freezer`, `devices`, `platform`, etc.) | All phases pass | | Verified no `event_count` increases during suspend | Confirmed | | Observed `last_change` updates for `0-003a` and `gpio-keys` | Confirmed | | Using `deep` sleep instead of `s2idle` | Same immediate resume | | No new boot ID or panic → not a reset | Confirmed | --- ### Interpretation - Suspend never actually completes; the system aborts before entering low power. - The abort is triggered by a state change on the lid sensor or its GPIO line. - This appears to be a firmware or kernel driver issue in the `gpio-keys` or I²C lid-sensor path on the Snapdragon X Elite platform. - The behavior matches a “spurious lid wake” or “suspend veto” rather than a true wakeup event. --- ### Expected behavior System should remain suspended until: - the lid is physically opened, or - the power button is pressed. --- ### Relevant logs Example (`deep` suspend attempt): ``` PM: suspend entry (deep) Disabling non-boot CPUs ... psci: CPU11 killed ... ... psci: CPU1 killed ... Enabling non-boot CPUs ... PM: suspend exit ``` see suspend_example.txt for full `dmesg` logs. --- ### Additional information `` $ cat /sys/power/mem_sleep [s2idle] deep ``` - Kernel: `Linux 6.14.x-generic` - Firmware package: `linux-firmware 2025.xx.xx` - BIOS/UEFI version: `N42ET92W (2.22 )` - `/sys/kernel/debug/wakeup_sources` shows only `last_change` updates for `0-003a` and `gpio-keys`. --- ### Summary / Request Suspend aborts immediately on Lenovo T14s Gen 6 (Snapdragon X Elite) due to apparent spurious lid-sensor activity (`gpio-keys` / `0-003a`). No device shows a real wake event; suspend never reaches a low-power state. Please investigate possible issues in: - `drivers/input/keyboard/gpio_keys.c` - Qualcomm/Lenovo lid sensor handling in device tree or firmware - Power management flow for Snapdragon X1E80100 (PSCI / PDC suspend entry) Logs and wakeup source diffs can be provided on request. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2127013/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
