Bug 216930
Summary: | closing laptop lid wakes from suspend Lenovo Slim 7 Pro | ||
---|---|---|---|
Product: | Power Management | Reporter: | regulator (tristang) |
Component: | Hibernation/Suspend | Assignee: | Mario Limonciello (AMD) (mario.limonciello) |
Status: | RESOLVED DOCUMENTED | ||
Severity: | low | CC: | mario.limonciello, regressions |
Priority: | P1 | ||
Hardware: | AMD | ||
OS: | Linux | ||
Kernel Version: | Linux fedora 6.0.18-300.fc37.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
regulator
2023-01-14 23:15:40 UTC
Please check if this still happens with 6.1.y and report back. Or is possible try mainline, too. Ideally use vanilla kernels. Agree - please test with 6.1.6. If you can still reproduce: can you please reproduce this issue while running a suspend using this script? https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py This will capture specific debug information that is relevant. I suspect this is caused by the WLAN card, but your debug output from the script will confirm it. Hi guys thanks for the reply, Fedora is currently on 6.1.5 kernel so I will test next release I am suspicious of my wifi adapter as I did see some red errors in the logs, I might order an AX210 and see if that resolves the issue Current adapter: Realtek RTL8852AE 802.11ax PCIe Wireless Network Adapter driver: rtw89_8852ae P.S. Mario thanks for all the work you have done on AMD Pstate! > Fedora is currently on 6.1.5 kernel so I will test next release 6.1.5 would be fine as well. The report will capture a bunch of otherwise useful debugging stuff. > I am suspicious of my wifi adapter as I did see some red errors in the logs A full dmesg would be good to illustrate what you're seeing. > P.S. Mario thanks for all the work you have done on AMD Pstate! :) Hi Mario, sorry that script didn't work on Fedora, perhaps it only works on debian hosts? I have the default python3, pip etc, error below Also heres the full DMesg log (boot up, login, click suspend, close lid after a minute: https://gist.github.com/regulator-g/a390215293d2b4006f216f32168fb3d3 python amd_s2idle.py Logs will be saved to s2idle_report.txt Traceback (most recent call last): File "/home/gaben/Downloads/amd_s2idle.py", line 237, in __init__ self.iasl = subprocess.call(["iasl", "-v"], stdout=subprocess.DEVNULL) == 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/subprocess.py", line 389, in call with Popen(*popenargs, **kwargs) as p: ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/subprocess.py", line 1024, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/lib64/python3.11/subprocess.py", line 1901, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: 'iasl' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/gaben/Downloads/amd_s2idle.py", line 886, in <module> app = S0i3Validator(args.log, args.acpidump) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/gaben/Downloads/amd_s2idle.py", line 242, in __init__ if installer: ^^^^^^^^^ UnboundLocalError: cannot access local variable 'installer' where it is not associated with a value (In reply to regulator from comment #5) > Hi Mario, sorry that script didn't work on Fedora, >[...] > self.iasl = subprocess.call(["iasl", "-v"], stdout=subprocess.DEVNULL) > == 0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib64/python3.11/subprocess.py", line 389, in call > with Popen(*popenargs, **kwargs) as p: > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib64/python3.11/subprocess.py", line 1024, in __init__ > self._execute_child(args, executable, preexec_fn, close_fds, > File "/usr/lib64/python3.11/subprocess.py", line 1901, in _execute_child > raise child_exception_type(errno_num, err_msg, err_filename) > FileNotFoundError: [Errno 2] No such file or directory: 'iasl' Didn't try, but I'd assume this can be resolved by running this: sudo dnf install -y /usr/bin/iasl thanks here is the script output from a simple run: https://gist.github.com/regulator-g/60e36f3ea10be343a8e94c16dd2be17b here is the script output when i ran triggered the script then closed the lid after 2seconds: https://gist.github.com/regulator-g/5a8c0abc6db8a53c64271aaba8f6e6b5 As a W/A can you please try to disable wakeup for: /sys/bus/serio/devices/serio0/power/wakeup If that doesn't work, can you please switch to 6.1.7 or at least take this patch from 6.1.7 and re-run the script. It will capture active GPIOs: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=046c9972dd40775cff4d12294ca14b0b624f2c35 > sudo dnf install -y /usr/bin/iasl
Thanks! Will add that to the script for the Fedora case.
Hi Mario, sorry for the late reply. I discovered a hint that in the dmesg log, whenever I close the lid this error appears, maybe the kernel does not understand the what the lid close event is properly [ 36.552900] ideapad_acpi VPC2004:00: Unknown event: 12 I am now using an AX210 wifi adapter and kernel 6.1.7. s2idle report (did not touch the lid or have anything open: https://gist.github.com/regulator-g/f917fea0c753427b0554bf638e842bfb full dmesg log: https://gist.github.com/regulator-g/e127ac4247757209c96974ecf3948804 > s2idle report (did not touch the lid or have anything open: > https://gist.github.com/regulator-g/f917fea0c753427b0554bf638e842bfb Can you please reproduce this with a longer timeout set (there is an argument to this script) and then while waiting for the timeout close the lid to trigger the behavior? > [ 36.552900] ideapad_acpi VPC2004:00: Unknown event: 12 In case it's related to the kernel driver you can try to blacklist this driver and see if that changes anything or it's a red herring. We don't know right now. > In case it's related to the kernel driver you can try to blacklist this
> driver and see if that changes anything or it's a red herring. We don't know
> right now.
I looked through the ideapad-laptop driver and suspect this is a red herring. Other similar platform-x86 drivers don't plumb the lid events, so this is probably the way to solve it.
diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
index 0eb5bfdd823a1..f5ec9295c08d0 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -1565,6 +1565,11 @@ static void ideapad_acpi_notify(acpi_handle handle, u32 event, void *data)
case 6:
ideapad_input_report(priv, bit);
break;
+ case 12:
+ /*
+ * lid close event, processed by ACPI already
+ */
+ break;
case 10:
/*
* This event gets send on a Yoga 300-11IBR when the EC
> As a W/A can you please try to disable wakeup for: > /sys/bus/serio/devices/serio0/power/wakeup Did you ever get a chance to try this? If it helps, then https://github.com/torvalds/linux/commit/8e60615e8932167057b363c11a7835da7f007106 will fix it too. sorry changing the wakeup did not help, I'll try it again just in case s2idle report with lid close at 12seconds: https://gist.github.com/regulator-g/126272a7e8c24f5cfdf8d7e33ce344af regarding that ideapad-laptop.c file, is that in the kernel? > 2023-01-30 13:25:49,834 DEBUG: PM: Triggering wakeup from IRQ 1 > 2023-01-30 13:25:49,834 DEBUG: PM: Triggering wakeup from IRQ 7 > 2023-01-30 13:25:49,834 DEBUG: PM: Triggering wakeup from IRQ 0 This shows a wakeup from the GPIO controller and the keyboard. > 2023-01-30 13:25:49,835 DEBUG: amd_gpio AMDI0030:00: GPIO 0 is active: > 0x300578e3 The GPIO that was active is GPIO #0. > 2023-01-30 13:25:36,105 DEBUG: Case (Zero) > 2023-01-30 13:25:36,105 DEBUG: { > 2023-01-30 13:25:36,105 DEBUG: Local0 = > \_SB.PCI0.LPC0.EC0.HWAK /* External reference */ > 2023-01-30 13:25:36,105 DEBUG: If (((Local0 & > 0x04) == 0x04)) > 2023-01-30 13:25:36,105 DEBUG: { > 2023-01-30 13:25:36,105 DEBUG: > \_SB.PCI0.LPC0.EC0.LIDO () > 2023-01-30 13:25:36,105 DEBUG: Sleep (0x01F4) > 2023-01-30 13:25:36,105 DEBUG: Local0 &= > 0xFFFB > 2023-01-30 13:25:36,105 DEBUG: > \_SB.PCI0.LPC0.EC0.HWAK = Local0 > 2023-01-30 13:25:36,105 DEBUG: } Over here is the code that is supposed to run for GPIO#0. Basically it is supposed to be checking if lid is active and do some stuff and go back to sleep. Given you didn't actually trigger the keyboard, I do strongly suspect this is the same IRQ1 bug I mentioned. If you can please apply that patch that I linked and reproduce it again the same way we can try to rule that out. > regarding that ideapad-laptop.c file, is that in the kernel? Yes Ok thanks Mario. Last time I tried to compile my own kernel it failed but I will try again with another guide (In reply to regulator from comment #16) > Ok thanks Mario. Last time I tried to compile my own kernel it failed but I > will try again with another guide Have you found time to test something? BTW, if you still look for a guide, maybe this one will be helpful (even if it's still WIP): https://www.leemhuis.info/files/misc/How%20to%20quickly%20build%20a%20trimmed%20Linux%20kernel%20%e2%80%94%20The%20Linux%20Kernel%20documentation.html sorry for the late reply, After a few attempts I managed to build the kernel including the patch for amd pmc.c, when I cat seri0/power/wakeup its disabled etc, unfortunately laptop still wakes up when closing the lid. The report looks slightly different.. https://gist.github.com/regulator-g/3870be600beba89ba4110a87c2af754f Thanks for the guide might be better than the one I used as modules seemed a bit messed up and not many guides explain what options to turn on/off in the kernel menu This is different now (even if it's the same symptoms). Can I please see a full acpidump for your system? We need to see what _CRS specifies GPIO 16, so we can see what it is connected to. I ran acpidump hopefully this is what you need: https://gist.github.com/regulator-g/861cfd87443eea14765c1cc43c6a8d7b GPIO 16 looks that it's a PNP0C50 I2C device, ITE8350. Is that a touchscreen I guess? Can you try to turn it off in BIOS setup to see if it helps the issue? Or possibly can you try `modprobe.blacklist=i2c-hid` to disable it and see if it helps? Hi Mario, It's not a touch screen, the screen does have brightness and some sort of proximity sensor on it, or perhaps the screen closing is registering something on the touchpad? I am worried that this issue is taking up a bit too much time vs the value that the fix is worth, unless this is a common issue that other people have too, happy to leave it for now. I will be going back to a thinkpad or other Linux supported machine next purchase! > It's not a touch screen, the screen does have brightness and some sort of > proximity sensor on it, or perhaps the screen closing is registering > something on the touchpad? That sounds quite plausible to me actually. Here is the part: https://www.ite.com.tw/en/product/view?mid=92 > I am worried that this issue is taking up a bit too much time vs the value > that the fix is worth, unless this is a common issue that other people have > too, happy to leave it for now. I will be going back to a thinkpad or other > Linux supported machine next purchase! OK, let's close as documented for now then. Thanks! |