https://bugzilla.kernel.org/show_bug.cgi?id=221217
Daniel Gibson ([email protected]) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Daniel Gibson ([email protected]) --- Hi, can you provide that minimal SSDT with the stub? I have an IdeaPad Slim 3 16ABR8 with BIOS KYCN41WW (also tested KYCN39WW) here and am seeing similar (but not quite the same) issues. I'm using XUbuntu 26.04 with Kernel 7.0 from their mainline repo. Suspend and resume *do* work here, but afterwards the keyboard doesn't work anymore, and neither does the lid switch. Adding `i8042.nopnp` to the kernel commandline makes the keyboard mostly work after suspend+resume, except the Fn keys don't work anymore (e.g. only as F1, not as Mute) and the lid switch is still broken. So using the lid switch to suspend only works once, afterwards the lid switch apparently doesn't send events anymore until I reboot. I found out the unloading the `amd_pcm` driver makes the issues disappear, but it also makes the laptop draw more power while suspended. I guess in that case some devices aren't sent to sleep, so they're not broken by sleep+resume issues, but they're also still drawing power? I've seen the same ACPI error and worked around it by fixing the call in ssdt14.dsl (so it calls `\_SB.PCI0.LPC0.EC0.SNTM ()`), but that didn't really make a difference for my problems. Still, shouldn't hurt to fix this and your workaround sounds more elegant :) I've also tried running `amd-s2idle test` (from amd-debug-tools), but it refused to run because "GPIO interrupt is not served". It suggests loading the i2c-hid-acpi kernel module, but it is already loaded. So I checked `/sys/kernel/debug/gpio` and it contained the line > #89 🔥 😷| ↓| level| | | | | | ↓ |input ↓| > |0x10240b00 Apparently that fire emoji means that this GPIO interrupt is not served. Is this the same GPIO line that causes trouble on your machine? How did you find out what device the line belongs to? Could the devices driver be fixed to serve that line? I could provide a lot more information (e.g. outputs of dmesg with kernel debug options enabled, lspci, the ACPI dump), but I wonder if I should do this here or if I should create a separate bugreport. By the way, there are other bugreports with similar/related issues, like #218092 , #220521 , #209923 , #216101 (closed), #216473 (closed) maybe #218003 And posts in the Archlinux Forum that suggest that the issues are fixed: https://bbs.archlinux.org/viewtopic.php?id=279102 and https://bbs.archlinux.org/viewtopic.php?id=293597 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
