Bug 216473
Summary: | keyboard failures after suspend/resume AMD Ryzen 9 6900HS Creator Edition | ||
---|---|---|---|
Product: | ACPI | Reporter: | Travis Glenn Hansen (travisghansen) |
Component: | Other | Assignee: | Mario Limonciello (AMD) (mario.limonciello) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | mario.limonciello, shyam-sundar.s-k, tim |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.19.7 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
logs
logs with acpi.prefer_microsoft_guid=1 dmidecode |
Description
Travis Glenn Hansen
2022-09-12 03:12:50 UTC
Can you please share the following: 1. An acpidump from your system. 2. A full dmesg including suspend/resume with pm_debug_messages acpi.dyndbg='file drivers/acpi/x86/s2idle.c +p' On your kernel command line. Created attachment 301789 [details]
logs
In the previous attachment make note that I did not experience the issue where the keyboard fails entirely. Your system definitely has some ASL that isn't called for the AMD paths that is called for the Microsoft path. On the way "down", the Microsoft side calls: Screen Off: WECM (0x6F, 0xEC) M000 (0x3E03) M460 (" Return (0x00)\n", Zero, Zero, Zero, Zero, Zero, Zero) \_SB.PCI0.LPC0.EC0.PLED = One \_SB.PCI0.LPC0.EC0.G140 = Zero \_SB.PCI0.LPC0.EC0.G155 = Zero Return (Zero) Modern Standby Entry: \_SB.PCI0.LPC0.EC0.ECMO = One M000 (0x3E07) M460 (" Return (0x00)\n", Zero, Zero, Zero, Zero, Zero, Zero) Return (Zero) On AMD path it calls: Screen Off: M000 (0x3E02) M460 (" Return (0x00)\n", Zero, Zero, Zero, Zero, Zero, Zero) Return (Zero) Modern Standby entry: M000 (0x3E04) M460 (" Return (0x00)\n", Zero, Zero, Zero, Zero, Zero, Zero) Return (Zero) So with the patches from #216101 can you please apply acpi.prefer_microsoft_guid=1? I noticed you used s2idle.prefer_microsoft_guid=1 in the other bug. Share an updated dmesg log with the same other debug parameters. Yes! I originally saw the feature here which mentions the incorrect option unfortunately: https://www.phoronix.com/news/AMD-s2idle-Rembrandt-ASUS Attaching logs shortly. Do you think the issue of the keyboard not working at all is even remotely related? Created attachment 301793 [details]
logs with acpi.prefer_microsoft_guid=1
> To get the keyboard to work at all this patch is currently required: > https://lore.kernel.org/all/CAJZ5v0isLQVX3EqsokFthY5ka=V4Vse9T52s3EGSv41FKM1iGw@mail.gmail.com/ FYI that patch should already be in 6.0. > I originally saw the feature here which mentions the incorrect option > unfortunately: https://www.phoronix.com/news/AMD-s2idle-Rembrandt-ASUS Ah; whoops maybe that author will need to fix the parameter in the description. > logs with acpi.prefer_microsoft_guid=1 Presumably nothing is improved for you? > Do you think the issue of the keyboard not working at all is even remotely > related? It "could" be as as those variables that control something related to the EC could cause it to ignore certain input. > - sporadically the keyboard will fail entirely - when ^ does not occur all the media/brightness keys fail to work (this is unconditional and happens every time assuming the keyboard works at all As a guess does your machine support the screen flipping around the hinge so it can go into tablet or tent mode? Perhaps something is wrong related to that? Sorry that last comment was not clear. Suspend/resume issues appear to be fixed by the patch/param!
I have not had enough time to determine if the outright failure scenarios are also cleaned up, but in scenarios where the keyboard is working post resume, *all* keys now work for me.
The model I have is a touch screen, it is not however a 2-in-1 as the screen does not do a 360.
Where do we go from here? Add the model to the quirks? I can do a bit more cycles on the suspend/resume to see if I still have outright failures from time to time.
> FYI that patch should already be in 6.0.
I know, was just making it clear in the scenario it was at all relevant.
> Sorry that last comment was not clear. Suspend/resume issues appear to be
> fixed by the patch/param!
Ah phenomenal!
In this case can you please attach your dmidecode output? I'll roll you into a re-spun v2.
Created attachment 301796 [details]
dmidecode
I'll apply the new patch and remove the kernel param and report back. I applied v2 of the patch and confirmed no special kernel param is necessary now. Suspend/resume works with media keys coming back 100% every time so far. Also of note, it *may* also have fixed the issue where the keyboard just outright fails to work upon resume. Since the failures are/were sporadic it is hard to say yet, but since activating the patch it has not failed on me (probably about 15-20 suspend/resume cycles thus far). I'll keep trying for another couple of days and report back. Thanks for confirming. Feel free to add a `Tested-by` tag to the submission. I can confirm that the fn keys for the Slim Pro 7x are fixed by this patch for me as well. I wanted to add that the only weird thing (and this is just a visual thing) is that the power button LED continually flashes with this patch upon waking up; I don't think it did strictly that without the patch, but I'd have to reboot again with the patch disabled and check. It properly fades in and out with or without this patch during suspend. I haven't noticed to power button led doing anything of that nature on my setup. It slowly fades in and out while asleep (presumably expected) but otherwise is lit when not suspended. I have noticed that the power button does not actually register a keypress (seemingly). For example in gnome I have the 'put the computer to sleep when the power button is pressed' enabled but in my case with this laptop it does nothing. That could be a lenovo thing by design or not, but that's my experience thus far. It looks like it's tied to battery % left and is triggered around 20%. If you have less than roughly 20% left, the power button light flashes. If you have roughly 20% or more, it stays solid. I validated it does it during first boot, and in the BIOS, too. Looks like it's not related to the ACPI code at all - great! The kernel solution has been queued up for 6.1 (https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=888ca9c7955e3969df84f5a1bda2143be9fa365a) |