Lenovo L14/L15/P14s Gen2 fails to resume from s0ix
S0ix resume is flaky on my Lenovo ThinkPad P14s Gen2.
Kernel: v5.14.10 + patches from #1721 (comment 1077338)
Problems:
- It enters suspend just fine (breathing effect on lid/power button led). Neither pressing a key nor the power button wakes the machine from suspend. Opening the lid while suspended does trigger a very short spinup of the fan, but fails to wake. A USB keyboard does wake it from suspend.
I applied the patches from #1721 (comment 1077338) but they don't help.
- When rebooting after a S0ix suspend/resume cycle, the machine throws a beep error code (Fan Error) and shuts down if not bypassed (I haven't tried to). It boots fine afterwards.
Note:
- It failed to enter suspend at all prior to v5.14.9 (SMU timeout; supposedly resolved by platform/x86: amd-pmc: Increase the response register timeout)
I've attached kernel logs of a suspend/resume cycle. Please let me know what else makes sense.
Activity
How about if you're using
iommu=pt tsc=nowatchdog acpi_osi=Linuxas kernel flags? There's a looong two seriers post over at Lenovo regarding this: https://forums.lenovo.com/t5/Other-Linux-Discussions/Linux-S0ix-support-on-AMD-platforms/m-p/5098254?page=1Thanks for the pointers. Setting
iommu=pt(disabling iommu?) resolves the nvme page faults and makes it resume more swiftly, but none of the options enable the keyboard/powerbutton/lid to wake the machine.Notes:
- I've upgraded to v5.14.11 + GPIO patches.
- Occasionally I get a IRQ related WARN in early boot (also present on v5.14.9) - mentioning because pinctrl_amd seems relevant for S0ix resume:
Oct 07 00:15:37 p14s kernel: irq 9: nobody cared (try booting with the "irqpoll" option) Oct 07 00:15:37 p14s kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: P O 5.14.9 #1-NixOS Oct 07 00:15:37 p14s kernel: Hardware name: LENOVO 21A0CTO1WW/21A0CTO1WW, BIOS R1MET39W (1.09 ) 06/21/2021 Oct 07 00:15:37 p14s kernel: Call Trace: ... Oct 07 00:15:37 p14s kernel: handlers: Oct 07 00:15:37 p14s kernel: [<000000002fa92884>] acpi_irq Oct 07 00:15:37 p14s kernel: Disabling IRQ #9Somehow interrupts are unmasked without a handler present? Once fully booted
pinctrl_amdis listed as a handler.$ cat /sys/kernel/irq/9/actions acpi,pinctrl_amd $ cat /sys/kernel/irq/9/wakeup enabled
added s0ix label
- It enters suspend just fine (breathing effect on lid/power button led). Neither pressing a key nor the power button wakes the machine from suspend. Opening the lid while suspended does trigger a very short spinup of the fan, but fails to wake. A USB keyboard does wake it from suspend.
Can you share your
acpidump?This sounds like EC caused APU to wake but EC's notification didn't make it into the OS. This probably needs Lenovo to dig into for their EC/BIOS bug and/or explain what they're expecting from Linux that is missing.
- I've upgraded to v5.14.11 + GPIO patches.
Right so at least for future me to look at this issue again, it was these GPIO patches that are in 5.15: https://github.com/torvalds/linux/commit/7e6f8d6f4a42ef9b693ff1b49267c546931d4619#diff-80a328564e791b694e33bc73c0b275d6363f7509e1549be9608ddc93cb157126
You may need patches in 5.15 to get it working. Would you mind trying out latest tip? Two rounds of driver updates to amdgpu is in there. I successfully booted 5.15 on P14s Gen1 with latest BIOS (1.35) and suspend/resume s2idle, but not 5.14. There's 5.13/5.14 with special patchwork available.
You guys have a Gen1 vs Gen2 here, and the EC may work differently between them. The EC is supposed to be setting that GPIO when you press power button or internal keyboard key or lid event. This probably needs Lenovo's firmware team to look into.
It's always IRQ9?
Yes. Doesn't happen every time - in fact, mostly doesn't occur: 3 out of ~18 boots.
Can you share your
acpidump?Includes DSDT and SSDT. Also contains
/sys/kernel/debug/gpioand/proc/interrupts.Right so at least for future me to look at this issue again, it was these GPIO patches that are in 5.15
Just to confirm: these are the patches I applied.
This probably needs Lenovo to dig into for their EC/BIOS bug and/or explain what they're expecting from Linux that is missing.
Although they're probably in the best position to debug this, I'm not sure whether they are..
My own notes regarding ACPI/interrupts:
- IRQ #9 is the System Control Interrupt - i.e. the main interrupt raised for ACPI events.
-
SSDT14contains the descriptors related to GPIO signaled events:_AEIand_EVT - These GPIOs are registered by
drivers/gpio/gpiolib-acpi.cbut belong to the AMD GPIO controller (managed bypinctrl_amd).
They're all listed in
/proc/interrupts:9: IR-IO-APIC 9-fasteoi acpi, pinctrl_amd 78: amd_gpio 0 ACPI:Event 79: amd_gpio 44 ACPI:Event 80: amd_gpio 61 ACPI:Event 81: amd_gpio 62 ACPI:Event 82: amd_gpio 58 ACPI:Event 83: amd_gpio 59 ACPI:Event 84: amd_gpio 2 ACPI:Event 85: amd_gpio 9 ACPI:Event 86: amd_gpio 18 ACPI:Event 87: amd_gpio 7 ACPI:Event 88: amd_gpio 68 ACPI:EventThe only interrupt counts increasing during suspend tests are #9, #78 and #87.
ACPI GPIO #0 (Linux #78) seems to be related to various hardware switches -
HWAK(= Hardware wake?) is an EC register queried for the interrupt cause: its contents seem to indicateLIDO/LIDC,ACIN/ACOUorPWRB.Example:
Switch (ToInteger (Arg0)) { Case (0x00) { CM8G = 0xBB Local0 = \_SB.PCI0.LPC0.EC0.HWAK /* External reference */ If (((Local0 & 0x04) == 0x04)) { CM8G = 0xCC \_SB.PCI0.LPC0.EC0.LIDO () Sleep (0x01F4) Local0 &= 0xFFFB \_SB.PCI0.LPC0.EC0.HWAK = Local0 }- Every time I suspend/resume using a USB keyboard and check
/proc/interruptspre/post the SCI (#9) count increases by 18 - Somewhat expected, if I press any (non-USB keyboard) key, power button or open the lid during suspend the SCI count increases by one more (19 total), and ACPI GPIO #0 increases by one as well (regardless of the number of times pressed).
- ACPI GPIO #7 increases every cycle - this seems tied to a device labeled
RTL8(Realtek?)
Based on the above, it seems an interrupt is definitely raised and reaches the OS eventually - though I wonder whether that happens during suspend, or only after being awaken by a different source.
Yes. Doesn't happen every time - in fact, mostly doesn't occur: 3 out of ~18 boots.
It's a long shot, but see if https://lore.kernel.org/linux-gpio/20211001161714.2053597-1-nakato@nakato.io/T/#m5b7d6d41a1ca0904001d4865c469082965919cf2 might help you with the IRQ9 issue.
Based on the above, it seems an interrupt is definitely raised and reaches the OS eventually - though I wonder whether that happens during suspend, or only after being awaken by a different source.
From what you've shared it seems in Lenovo's design that the EC acts like an arbitrator of sorts for when to assert the APU's GPIO00. All the events you mentioned are supposed to come back to GPIO00 for an interrupt. This evidence also reaffirms why I think this is the EC's issue due to missing a notification or so.
This could be as simple as they expected some driver to call _STA or a _DSM on the way down since that's how it works on Windows ACPI but that doesn't happen with ACPICA in Linux.
it seems an interrupt is definitely raised and reaches the OS eventually
Which I guess makes sense? The EC queued up the event for the next wakeup and you use the USB keyboard to wakeup and then it goes through.
It's a long shot, but see if https://lore.kernel.org/linux-gpio/20211001161714.2053597-1-nakato@nakato.io/T/#m5b7d6d41a1ca0904001d4865c469082965919cf2 might help you with the IRQ9 issue.
Will do.
Which I guess makes sense? The EC queued up the event for the next wakeup and you use the USB keyboard to wakeup and then it goes through.
Isn't the EC supposed to actually wake the APU by asserting GPIO00? What if the EC asserts it but the APU (somehow) fails to notice until it's woken up via other means (for example, a USB keyboard / XHCI interrupt?)
Isn't the EC supposed to actually wake the APU by asserting GPIO00? What if the EC asserts it but the APU (somehow) fails to notice until it's woken up via other means (for example, a USB keyboard / XHCI interrupt?)
Yes, the keyboard wakeup works via the XHCI controller asserting a GPIO. Power button wakeup works via power button press caught by the EC (and debounced) and then EC asserts a GPIO. From the APU's perspective it just looks for that edge trigger from the EC while in s0i3. If the EC doesn't send it while down then we have this issue.
I have another (non-Lenovo) system that wakes from GPIO00 via a power button that is debounced by an EC. It start working with those GPIO patches for 5.15 linked above you confirmed you applied. Looking at my
/sys/kernel/debug/gpiooutput for GPIO00:pin0 Edge trigger| Active high| interrupt is enabled| interrupt is unmasked| enable wakeup in S0i3 state| enable wakeup in S3 state| disable wakeup in S4/S5 state| input is high| 4k pull-up| pull-up is enabled| Pull-down is disabled| output is disabled| debouncing filter (high and low) enabled| debouncing timeout is 0 (us)| 0x1578e0Contrasting it with yours:
pin0 Edge trigger| Active high| interrupt is enabled| interrupt is unmasked| enable wakeup in S0i3 state| enable wakeup in S3 state| enable wakeup in S4/S5 state| input is high| pull-up is disabled| Pull-down is disabled| output is disabled| debouncing filter (high and low) enabled| debouncing timeout is 0 (us)| 0x5f8e0The only difference in the configuration is that mine has a 4k pull up configured and yours doesn't. This may be a hardware difference in Lenovo's design versus the one I'm using. Given the power button "works" at runtime I don't think that's likely the cause.
I wonder if Lenovo really expects the EC registers to be read from the OS even in s0i3. What this would mean is that EC GPE has to be allowed to wake the system so that EC registers can be read and then system needs to go back into s0i3 if it shouldn't be a wake event. IOW:
- Some combination of reverting 7b167c4cb48ee3912f0068b9ea5ea4eacc1a5e36 and other TBD changes.
- Adding a quirk for some Lenovo systems to not apply 7b167c4cb48ee3912f0068b9ea5ea4eacc1a5e36 behavior (or have another lenovo specific driver mark as a wakeup source)
Every time I suspend/resume using a USB keyboard and check
/proc/interruptspre/post the SCI (#9 (closed)) count increases by 18Do you see anything around one of these two that time?
82: amd_gpio 58 ACPI:Event 83: amd_gpio 59 ACPI:Event
I'd like to add another interesting discovery.
I enabled PM debugging:
echo 1 > /sys/power/pm_debug_messages, suspended the machine, pressed the power button (fan spins momentarily), then a few seconds later woke the machine using USB.[36505.903636] PM: suspend entry (s2idle) [36510.181531] Filesystems sync: 4.277 seconds [36510.181537] PM: Preparing system for sleep (s2idle) [36510.182020] Freezing user space processes ... (elapsed 0.002 seconds) done. [36510.184193] OOM killer disabled. [36510.184194] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [36510.185280] PM: Suspending system (s2idle) [36510.185281] printk: Suspending console(s) (use no_console_suspend to debug) [36510.557335] PM: suspend of devices complete after 371.911 msecs [36510.557347] PM: start suspend of devices complete after 372.064 msecs [36510.557866] PM: late suspend of devices complete after 0.514 msecs [36510.558912] ACPI: EC: interrupt blocked [36510.681499] PM: noirq suspend of devices complete after 123.416 msecs [36510.681509] ACPI: \_SB_.PCI0.GPP5: LPI: Constraint not met; min power state:D1 current power state:D0 [36511.093554] PM: suspend-to-idle [36522.765829] PM: Timekeeping suspended for 12.269 seconds [36527.245017] PM: Timekeeping suspended for 3.717 seconds [36527.245246] PM: ACPI non-EC GPE wakeup [36527.245253] PM: resume from suspend-to-idle [36527.881972] ACPI: EC: interrupt unblocked [36527.919329] PM: noirq resume of devices complete after 37.584 msecs [36527.922912] PM: early resume of devices complete after 3.237 msecsNote the
Timekeeping suspendedmessage being repeated. The first message appears to correlate with my power button press. I then enabled allpowercategory tracepoints (except forpower:cpu_idle) and repeated the sequence:systemd-sleep-46020 [004] .... 39822.048689: suspend_resume: dpm_suspend_noirq[2] end systemd-sleep-46020 [004] .... 39822.467512: suspend_resume: machine_suspend[1] begin <idle>-0 [013] d... 39822.467822: suspend_resume: timekeeping_freeze[13] begin <idle>-0 [001] dN.. 39826.230096: suspend_resume: timekeeping_freeze[1] end systemd-sleep-46020 [004] .... 39826.230266: suspend_resume: machine_suspend[1] end systemd-sleep-46020 [004] .... 39826.230307: suspend_resume: machine_suspend[1] begin systemd-sleep-46020 [004] .... 39826.230454: suspend_resume: machine_suspend[1] end systemd-sleep-46020 [004] .... 39826.230492: suspend_resume: machine_suspend[1] begin [..] systemd-sleep-46020 [004] .... 39826.632074: suspend_resume: machine_suspend[1] begin <idle>-0 [004] d... 39826.632092: suspend_resume: timekeeping_freeze[4] begin <idle>-0 [009] dN.. 39833.170834: suspend_resume: timekeeping_freeze[9] end systemd-sleep-46020 [004] .... 39833.171019: suspend_resume: machine_suspend[1] end kworker/0:0-24473 [000] d... 39833.279037: wakeup_source_activate: device:01 state=0x31140001 kworker/0:0-24473 [000] d... 39833.279039: wakeup_source_deactivate: device:01 state=0x31150000 kworker/0:0-24473 [000] d... 39833.279047: wakeup_source_activate: 0000:06:00.0 state=0x31150001 <idle>-0 [000] d.s. 39833.382781: wakeup_source_deactivate: 0000:06:00.0 state=0x31160000 kworker/0:0-24473 [000] d... 39833.593562: wakeup_source_activate: PNP0C0D:00 state=0x31160001 kworker/0:0-24473 [000] d... 39833.593562: wakeup_source_deactivate: PNP0C0D:00 state=0x31170000 kworker/0:0-24473 [000] d... 39833.593565: wakeup_source_activate: device:0c state=0x31170001 kworker/0:0-24473 [000] d... 39833.593565: wakeup_source_deactivate: device:0c state=0x31180000 kworker/0:0-24473 [000] d... 39833.593566: wakeup_source_activate: 0000:00:02.2 state=0x31180001 <idle>-0 [000] d.s. 39833.694780: wakeup_source_deactivate: 0000:00:02.2 state=0x31190000 systemd-sleep-46020 [004] .... 39833.799675: suspend_resume: dpm_resume_noirq[16] begin kworker/u32:19-44287 [002] .... 39833.799864: device_pm_callback_start: pci 0000:00:00.0, parent: pci0000:00, noirq bus [resume] kworker/u32:19-44287 [002] .... 39833.799894: device_pm_callback_end: pci 0000:00:00.0, err=0Notes:
- The machine suspends at 39822
- The power button is pressed at 39826, after which
machine_suspendandtimekeeping_freezeare repeated a large number of times before returning to idle - The USB interrupt (actual resume) occurs at 39833
It seems the machine in fact is woken up? This suggests it might be spinning in
kernel/power/suspend.c:s2idle_looplooking for a valid wakeup source?Interesting finding - can you please check
/sys/kernel/debug/amd_pmc/smu_fw_info? There is a S0i3 cycle count. When you wakeup from just keyboard it should be "1". When you "wakeup" from power button and nothing happens, but then wakeup from keyboard does it bump up to 2 or higher (based on number of presses?)?When you wakeup from just keyboard it should be "1"
Ack.
When you "wakeup" from power button and nothing happens, but then wakeup from keyboard does it bump up to 2 or higher (based on number of presses?)?
Indeed, it bumps to 2 (regardless of how many times I press the power button or laptop keyboard).
It doesn't mean that the GPIO that should have been used to trigger the wakeup has actually been asserted.
Sounds fair.
Related: how is it supposed to exit the s2idle loop? I'm not sure which of the checks in
acpi_s2idle_wakeshould returntruewhen a GPIO is asserted? In part because it does seem to check for GPEs, but reading the ACPI specs I got the idea that GPIO signaled events are distinct from GPEs? Aren't we supposed to end up inpinctrl_amd's interrupt handler so it can check whether one of the pins was the wakeup source? How are we supposed to get there?Edited by iusRelated: how is it supposed to exit the s2idle loop? I'm not sure which of the checks in
acpi_s2idle_wakeshould returntruewhen a GPIO is asserted?It's supposed to exit here: https://github.com/torvalds/linux/blob/349a2d52ffe59b7a0c5876fa7ee9f3eaf188b830/drivers/acpi/sleep.c#L723
In part because it does seem to check for GPEs, but reading the ACPI specs I got the idea that GPIO signaled events are distinct from GPEs? Aren't we supposed to end up in
pinctrl_amd's interrupt handler so it can check whether one of the pins was the wakeup source? How are we supposed to get there?Remember there is some hardware here that is programmed. When you see
/sys/kernel/debug/gpioyou can see the configuration for all the pins and what context they're supposed to do something. Also specifically remember https://github.com/torvalds/linux/commit/acd47b9f28e55b505aedb842131b40904e151d7c fixed things. This sets the IRQ for the controller itself to be a valid wake source. So a GPIO is asserted, controller sees it and if in the right state the controller asserts an IRQ. OS gets the IRQ and does the wakeup handling (calling into that handler).Probably a good reference from on my local system that has all this working: I put it to sleep with
systemctl suspend. I wake it up with the power button press. Here's what I see withpm_debug_messagesset:[ 8166.257361] PM: suspend-to-idle [ 8166.245312] PM: Timekeeping suspended for 15.876 seconds [ 8166.260730] PM: Wakeup unrelated to ACPI SCI [ 8166.260730] PM: resume from suspend-to-idleFrom diffing
/proc/interruptsbefore and after:--- old 2021-10-14 15:49:31.573782310 -0500 +++ new 2021-10-14 15:50:30.944126834 -0500 @@ -1,11 +1,11 @@ CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 0: 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 2-edge timer - 1: 0 0 0 0 0 0 0 39 0 0 0 0 0 0 0 0 IR-IO-APIC 1-edge i8042 - 7: 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 7-fasteoi pinctrl_amd + 1: 0 0 0 0 0 0 0 54 0 0 0 0 0 0 0 0 IR-IO-APIC 1-edge i8042 + 7: 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 7-fasteoi pinctrl_amd 8: 0 0 0 0 0 0 0 0 14 0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0 - 9: 0 109 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi + 9: 0 123 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi 25: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IOMMU-MSI 0-edge AMD-Vi - 26: 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 0 ACPI:Event + 26: 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 0 ACPI:Event 27: 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 44 ACPI:Event 28: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 61 ACPI:Event 29: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 amd_gpio 62 ACPI:EventThere's a few things in there that incremented across suspend, but the important ones that went up by exactly 1 are:
- IRQ7 (the GPIO controller IRQ)
- IRQ26 (the power button press).
Thanks for the explanation & example.
- IRQ7 (the GPIO controller IRQ)
Interesting, your machine appears to have a dedicated IRQ line for the GPIO controller..
Mine doesn't, and it appears to be shared with the ACPI SCI (I assumed that would always be the case as per ACPI spec, although I couldn't find a description/example of interrupt flow for GPIO signaled interrupts)
9-fasteoi acpi, pinctrl_amd
You pointed out we're supposed to leave via the 'SCI is still armed' path.
Which begs the question, how's that supposed to work in my case if the GPIO controller shares the SCI IRQ?
I did check two other working machines that I have in my possession (HP 635 RN and Lenovo P14s RN) and both are configured the same as my working reference machine I shared the example from where
pinctrl_amdis onIRQ7andacpiis onIRQ9.So this might be an assumption in the s2idle handling code that needs adjusting for how your machine is doing it.
What would be really useful to rule out an EC problem would be to pop a scope on the APU's GPIO00 or EC's GPIO output and confirm whether it asserts, but I guess that's out of the question :)Have a try with this patch: 0001-pinctrl-amd-Fix-wakeups-when-IRQ-is-shared-with-SCI.patch
Yes, that works!
FWIW, I had done some crude testing of my own (checking & bailing on GPIO00 in
s2idle_loop) in the meantime, which revealsBIT(WAKE_STS_OFF)andBIT(INTERRUPT_STS_OFF)are both set - wonder whether it makes sense to explicitly check for the wake bit only.Notes:
- It reliably resumes on GPIO wake now - great!
- GPIO00 is also asserted on lid close or AC unplug - which means these events also resume from suspend (not sure how that works on other devices?)
At the risk of mixing things up: I ran into a seemingly unrelated suspend failure while testing; it first throws a SMU timeout (timestamp: 691), after which it immediately re-attempts to suspend (timestamp: 698.602768; unsure whether I manually triggered that), now catastrophically locking up in amdgpu: dmesg_smu_timeout.log
Edited by iusFWIW, I had done some crude testing of my own (checking & bailing on GPIO00 in
s2idle_loop) in the meantime, which revealsBIT(WAKE_STS_OFF)andBIT(INTERRUPT_STS_OFF)are both set - wonder whether it makes sense to explicitly check for the wake bit only.Sure. Here's an updated patch for that. 0001-pinctrl-amd-Fix-wakeups-when-IRQ-is-shared-with-SCI.patch
- It reliably resumes on GPIO wake now - great!
- GPIO00 is also asserted on lid close or AC unplug - which means these events also resume from suspend (not sure how that works on other devices?)
I guess this is up to Lenovo's EC decisions what to do..
At the risk of mixing things up: I ran into a seemingly unrelated suspend failure while testing; it first throws a SMU timeout (timestamp: 691), after which it immediately re-attempts to suspend (timestamp: 698.602768; unsure whether I manually triggered that), now catastrophically locking up in amdgpu: dmesg_smu_timeout.log
I'd say split that off to another issue. One issue per ticket makes things easier to work with. The GPU looks pretty unhappy on the way down. I don't expect it to be caused by this patch (other than that you can reliably wake the system now so it's easier to hit other bugs).
Sure. Here's an updated patch for that.
Works just as fine. Thanks again!
I guess this is up to Lenovo's EC decisions what to do..
Shouldn't it just forward hardware events and leave it up to the OS to make decisions on how to handle them?
I'm still puzzled - how is a lid close handled on other platforms? Does it not raise a wake interrupt at all the machine is already in S0ix? Or does it exit the
s2idleloop, and re-enter suspend in some other way?I'd say split that off to another issue. One issue per ticket makes things easier to work with. The GPU looks pretty unhappy on the way down.
Should I manage to reproduce it reliably I'll do so.
Edited by iusWorks just as fine. Thanks again!
Great. If you can please add a
Tested-bytag to the upstream thread. If you're not familiar with doing it, it's basically download the 'raw' mbox file (https://lore.kernel.org/linux-gpio/20211015144332.700-1-mario.limonciello@amd.com/raw) and then open that in your email client and at the bottom reply withTested-by: Foo Bar <foo@bar.com>Shouldn't it just forward hardware events and leave it up to the OS to make decisions on how to handle them?
As I can tell there isn't a GPIO to the APU for the lid on your system. It seems that Lenovo instead uses APU GPIO00 to signal "something changed!" and then lets the OS figure out the state of everything on the machine through that ASL in
_EVT. So from a wakeup perspective that GPIO being asserted will get the system awake, the EC gets turned back on for processing and everything in the_EVTfor GPIO 00 runs. Try runningacpi_listenacross the suspend cycle and compare/proc/interruptsand you'll see what ACPI events map out to what GPIO.Looking at your
dmesgI do notice this:[ 30.373371] ACPI: button: The lid device is not compliant to SW_LID.You can see more about this here: https://github.com/torvalds/linux/blob/8e235ff9a1e3dc3d800224ab97bcd2418d3b19c3/drivers/acpi/button.c#L210
It's entirely possible another quirk for your system is needed related to how lid handling works.
I'm still puzzled - how is a lid close handled on other platforms? Does it not raise a wake interrupt at all the machine is already in S0ix? Or does it exit the
s2idleloop, and re-enter suspend in some other way?Some other platforms have the LID on their own GPIO, or a fixed ACPI HW event. Since it's just a single GPIO for any of the wakeup related things it's up to the EC to send that at the right time.
Should I manage to reproduce it reliably I'll do so.
Submitted that patch upstream: https://lore.kernel.org/linux-gpio/20211015144332.700-1-mario.limonciello@amd.com/T/#u Feel free to add a
Tested-Bytag if you would like.
