https://bugzilla.kernel.org/show_bug.cgi?id=218750
Bug ID: 218750 Summary: Regression: S0ix sleep broken on 13th Gen Lenovo laptops Product: ACPI Version: 2.5 Hardware: Intel OS: Linux Status: NEW Severity: blocking Priority: P3 Component: Power-Sleep-Wake Assignee: acpi_power-sleep-w...@kernel-bugs.osdl.org Reporter: mpearson-len...@squebb.ca Regression: No Hi, S0ix sleep is broken on X1 Carbon G11 and X1 Yoga G8 platforms (Raptorlake CPU). Still checking if other platforms from that generation are impacted. Bisect is pointing at: [banther@x1c11 linux]$ git bisect bad 073237281a508ac80ec025872ad7de50cfb5a28a is the first bad commit commit 073237281a508ac80ec025872ad7de50cfb5a28a Author: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Date: Tue Feb 6 20:33:45 2024 +0100 ACPI: PM: s2idle: Enable Low-Power S0 Idle MSFT UUID for non-AMD systems Systems based on Intel platforms that use the MSFT UUID for Low-Power S0 Idle (LPS0) have started to ship, so allow the kernel to use the MSFT UUID in the non-AMD case too, but in that case make it avoid evaluating the same _DSM function for two different UUIDs and prioritize the MSFT one. While at it, combine two MSFT _DSM function mask checks in acpi_s2idle_restore_early() so as to make it reflect the acpi_s2idle_prepare_late() flow more closely and adjust the Modern Standby entry and exit comments slightly. Non-AMD systems that do not support MSFT UUID for Low-power S0 Idle are not expected to be affected by this change in any way. Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Reviewed-by: Mario Limonciello <mario.limoncie...@amd.com> drivers/acpi/x86/s2idle.c | 37 +++++++++++++++++++++++++++---------- 1 file changed, 27 insertions(+), 10 deletions(-) I did some sanity checking and confirmed that if I force lps0_dsm_func_mask_microsoft = -EINVAL that S0ix works again. Can this change be reverted while we figure out how to fix this please? I'm happy to help with any testing, and can pull in Lenovo FW teams if FW level fixes are needed (with a note that those will take time, and I think this has to be reverted from 6.9 until the issue is root caused and understood). I'll note that I'm not seeing any problems on the Meteorlake system I have - so it may be platform or CPU version specific. I've not had time to confirm Thanks to Hans de Goede for notifying me of the issue in the 6.9-rc builds. Mark -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla