Bug 219445 - Lenovo Yoga Pro 7 14ASP9 fails to wake up from suspend mode
Summary: Lenovo Yoga Pro 7 14ASP9 fails to wake up from suspend mode
Status: NEW
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: AMD Linux
: P3 normal
Assignee: acpi_power-sleep-wake
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-30 16:10 UTC by 2835365572zty
Modified: 2024-11-04 00:25 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg last time I boot (126.37 KB, text/plain)
2024-10-30 16:10 UTC, 2835365572zty
Details

Description 2835365572zty 2024-10-30 16:10:01 UTC
Created attachment 307088 [details]
dmesg last time I boot

Description:
I recently received a new Lenovo Yoga Pro 7 14ASP9 and installed Linux on it (kernel version 6.11.5). Most hardware functions as expected out of the box, including Wi-Fi, Bluetooth, touchpad, keyboard backlight, audio, touchscreen, and graphics card. However, the system fails to wake up after entering sleep/suspend mode.

When the system goes into suspend, the power button indicator light continues flashing, but attempting to wake it by pressing the keyboard or the power button has no effect. The system remains unresponsive.

I also tried running sudo rtcwake -m mem -s 20 to test suspend mode, but the system did not wake up after the specified 20 seconds.

Hardware Information:
Device Model: Lenovo Yoga Pro 7 14ASP9
Linux Kernel Version: 6.11.5
dmesg log: https://linux-hardware.org/?probe=414716466d&log=dmesg.1
Full Hardware Probe: https://linux-hardware.org/?probe=414716466d

Steps to Reproduce:

1.Put the device into suspend/sleep mode via the power menu or by using sudo rtcwake -m mem -s 20.
2.Wait for the device to enter suspend, as indicated by the flashing power button light.
3.Attempt to wake the device by pressing any key or the power button.

Expected Behavior:
The device should resume from suspend mode, with the display and other system functions restored to a usable state.

Actual Behavior:
The device remains unresponsive, with only the power button indicator flashing. The system does not respond to key presses or the power button, requiring a forced reboot to recover.

Additional Notes:

1.This issue has been observed consistently with kernel version 6.11.5.
2.No errors or warnings related to this behavior appear in the logs leading up to suspend.
Comment 1 2835365572zty 2024-10-30 16:11:29 UTC
This is my first time submitting a bug report to the Linux kernel. If there’s anything incorrect or non-standard, please let me know, and I’ll be happy to conduct any necessary tests. Thank you for your understanding.
Comment 2 2835365572zty 2024-10-30 16:18:48 UTC
https://pastebin.com/eMTCCPp3

Here is loglevel7 version.
Comment 3 2835365572zty 2024-10-31 04:00:57 UTC
https://pastebin.com/1wafDf2c
Here is vanilla kernel with loglevel=7
Comment 4 2835365572zty 2024-10-31 12:42:06 UTC
I have tested several kernels, including 6.12-rc5 (kernel-default), 6.11 (kernel-default), 6.11 (kernel-vanilla), 6.12-rc5 on Fedora, and 6.10 (kernel-vanilla). Among these, only the 6.10 kernel-vanilla worked correctly, waking up properly.

Here is the dmesg log for kernel 6.10:
https://pastebin.com/xTQV0gqQ

And here is the dmesg log for kernel 6.12:
https://pastebin.com/D7MMHH2Z
Comment 5 The Linux kernel's regression tracker (Thorsten Leemhuis) 2024-11-01 12:46:32 UTC
If 6.10 worked and later don't it's a regression. This can be caused by all changes in various areas of the kernel, hence: could you bisect it?

https://docs.kernel.org/next/admin-guide/verify-bugs-and-bisect-regressions.html
https://docs.kernel.org/next/admin-guide/bug-bisect.html
Comment 6 2835365572zty 2024-11-01 13:24:08 UTC
I tried it with "nomodeset". It just woke up without any issue. So I think it is a issue related to AMDGPU. I'm going to do a bisect, give me 1-3days.
Comment 7 The Linux kernel's regression tracker (Thorsten Leemhuis) 2024-11-01 13:54:38 UTC
(In reply to 2835365572zty from comment #6)
> So I think it is a issue related to AMDGPU.

Possible, but even then it can be something amdgpu uses (say i2c) and thus something the i2c developer have to look into.
Comment 8 2835365572zty 2024-11-02 13:36:16 UTC
aoba@Aoba-Laptop-YOGA:~/Projects/Linuxes/linux> git bisect good
f6098641d3e1e4d4052ff9378857c831f9675f6b is the first bad commit
commit f6098641d3e1e4d4052ff9378857c831f9675f6b
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Tue Aug 6 09:55:55 2024 -0400

    drm/amd/display: fix s2idle entry for DCN3.5+
    
    To be able to get to the lowest power state when suspending systems with
    DCN3.5+, we must be in IPS before the display hardware is put into
    D3cold. So, to ensure that the system always reaches the lowest power
    state while suspending, force systems that support IPS to enter idle
    optimizations before entering D3cold.
    
    Reviewed-by: Roman Li <roman.li@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 237193e21b29d4aa0617ffeea3d6f49e72999708)
    Cc: stable@vger.kernel.org # 6.10+

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
 1 file changed, 3 insertions(+)
aoba@Aoba-Laptop-YOGA:~/Projects/Linuxes/linux>

I have finished it.
Comment 9 2835365572zty 2024-11-04 00:25:42 UTC
https://gitlab.freedesktop.org/drm/amd/-/issues/3738

Note You need to log in before you can comment on or make changes to this bug.