Public bug reported:
(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.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "dmesg logs showing wakeup happens after about 1 second
from suspend"
https://bugs.launchpad.net/bugs/2127013/+attachment/5916127/+files/suspend_example.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2127013
Title:
[BUG] Lenovo ThinkPad T14s Gen 6 (Snapdragon X Elite): immediate
resume / suspend abort (s2idle & deep)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2127013/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
