Same user-visible symptom on different hardware, but the EFI power-off approach does not fix it here — and I think I found the actual trigger.
System Lenovo Yoga Slim 7 Carbon 14ACN6 (type 82L0) AMD Ryzen 7 5800U (Cezanne) Insyde EFI v2.7, BIOS H5CN42WW / EC H5EC42WW Linux Mint 22.3, kernel 7.0.0-38-generic Symptom is identical: after systemctl poweroff the power LED goes out and ~1 s later the machine runs a full POST. systemctl hibernate behaves the same way, so it is not S5-specific. Reproduces from a live USB. Windows PE on the same machine shuts down correctly. The machine shipped with H5CN08WW and was fine; the symptom appeared right after the first BIOS update (by date almost certainly H5CN38WW, built 2022-09-29). Why the acpi_no_s5 / EFI power-off path does not help here I built an out-of-tree module registering an EFI_RESET_SHUTDOWN handler for SYS_OFF_MODE_POWER_OFF at SYS_OFF_PRIO_FIRMWARE + 2, so it preempts acpi_power_off. Confirmed it actually runs: a probe build calling emergency_restart() instead made the machine reboot on "shut down". With the real handler the firmware did power the board off — it never returned to the fallback — and the machine came back exactly as with ACPI S5. Root cause on this machine I dumped the FCH registers in two states: a boot with acpi=off (where a direct SLP_TYP=5|SLP_EN write to PM1a_CNT powers off and stays off) and a normal boot (where it does not). The FCH PM block at 0xFED80300 (0x100 bytes) is byte-for-byte identical. Exactly 20 GPIO pin registers at 0xFED81500 differ — the ones pinctrl-amd programs when it claims the GpioInt descriptors from \_SB.GPIO._AEI. pin firmware after pinctrl-amd 0x00 0x00050000 0x000578E3 0x02 0x00C50000 0x00447A00 0x08 0x00050000 0x00151B74 0x09 0x00052B00 0x00151B00 0x0B 0x00C50000 0x00457A00 0x11 0x00150000 0x00157A00 0x12 0x0005EB00 0x00057A00 0x18 0x00840000 0x00047A00 0x1D 0x00840000 0x00E50000 0x2C 0x00002800 0x00007800 0x31 0x00000000 0x00007900 0x36 0x00000000 0x00007A00 0x3A 0x0000E900 0x00007900 0x3B 0x0000E900 0x00007900 0x3D 0x00002800 0x00007900 0x3E 0x00002800 0x00007900 0x44 0x00C50000 0x00457800 0x4A 0x00040000 0x00050000 0x5B 0x00050000 0x00151B00 0x74 0x00050000 0x00151B00 Writing those 20 registers back to the firmware values immediately before the sleep-register write makes the machine power off and stay off. Moving that restore into a systemd-shutdown hook, so the kernel's normal ACPI power-off runs afterwards, gives a working "shut down" from the desktop: 10 consecutive cycles, no failures. ACPI stays fully enabled, no table overrides, firmware untouched, reboot unaffected. This also explains two things I could not account for before: GRUB's "halt" always powered the machine off correctly (it runs before pinctrl-amd exists), and Windows PE works (nothing there parses _AEI). Also ruled out, each tested and ineffective: every device in /proc/acpi/wakeup; acpi_mask_gpe for all active GPEs; acpi.ec_no_wakeup=1; WoWLAN; RTC alarm; USB and PCI power/wakeup plus PME_En/PME_Status; PM1_EN and BM_RLD variations; leaving ACPI mode via ACPI_DISABLE with SCI_EN confirmed cleared; all relevant BIOS options; EC reset; BIOS+EC update; unloading ideapad_laptop and amd_pmc; battery-only with rfkill and lid closed; SysRq 'o'; DSDT patches removing the SMI calls from the S5 branch of _PTS and skipping that branch entirely; disabling the EC through its _STA. Suggested direction pinctrl-amd already saves and restores the whole pin bank around suspend (amd_gpio_suspend / amd_gpio_resume) but has no shutdown path, so the driver's configuration is simply left in place on power-off. A .shutdown callback restoring the saved register values would cover this without any per-model quirk and would be a no-op where firmware does not care. If the T14 Gen 5 has the same root cause, that would explain why the EFI power-off module passed some shutdowns and failed others in the v1/v2 testing: the method of entering S5 is not the variable, the GPIO state is. Worth checking there — dump 0xFED81500 (0x400 bytes) under acpi=off and under a normal boot and diff them. Happy to test patches. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2162837 Title: ThinkPad T14 Gen 5 Intel automatically powers on after successful shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162837/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
