[REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Mikkel Sejdelin]

Resending as plain text; the previous copy was rejected by the lists for containing HTML.



Hi,

Since 6.18.57, my laptop never comes back from suspend-to-idle: on resume
init receives SIGRTMIN+4 and starts a poweroff, the display stays off, and
the machine hangs until it is forced off. 6.18.56 works fine.

Hardware: Lenovo IdeaPad Pro 5 16AKP10 (83JN), BIOS R1CN59WW, AMD, s2idle only
Distro:   NixOS 26.05 (distro kernel, CONFIG_ACPI_BUTTON=m,
          CONFIG_ACPI_TINY_POWER_BUTTON=m, CONFIG_ACPI_TINY_POWER_BUTTON_SIGNAL=38)

On every resume, the journal on 6.18.57 shows:

  kernel: PM: suspend entry (s2idle)
  systemd[1]: Received SIGRTMIN+4.
  systemd-sleep: System returned from sleep operation 'suspend'.
  kernel: PM: suspend exit
  systemd-sleep: Failed to thaw unit 'user.slice': Unit has a pending job

followed by:

  systemd[1]: Activating special unit System Power Off...
  systemd[1]: Cannot stop frozen unit Session 3 of User mikke.
  ...
  systemd-shutdown[1]: Sending SIGTERM to remaining processes...

after which the journal stops and the machine hangs with the display off
(SIGRTMIN+4 = poweroff.target in systemd). A bpftrace probe on signal
delivery to PID 1 shows the signal comes from a kernel worker, i.e. the
ACPI notify path, not from userspace:

  sig=38 code=128 from pid=296 comm=kworker/6:2

Cause:

6.18.57 contains 38c79dacc806 ("ACPI: button: Convert the driver to a
platform one", upstream 52d864019636), backported as a Stable-dep-of
fe80251152fe ("ACPI: button: Fix ACPI GPE handler leak during removal").
The matching upstream conversion of tiny-power-button, f4203ec64e11
("ACPI: tiny-power-button: Convert the driver to a platform one"), was
not backported.

Before the backport, both drivers were acpi_drivers matching PNP0C0C,
so only one could bind; button wins on this machine and tiny-power-button
stays unbound. After it, button binds to the platform device and
tiny-power-button binds to the ACPI companion of the same device, so both
install notify handlers on PWRB. tiny-power-button calls
kill_cad_pid(SIGRTMIN+4) for any notify, including the wake notification
on s2idle resume, which button itself filters out.

Verification on the same machine:

  6.18.56 (no blacklist):
    /sys/bus/acpi/drivers/button/            -> PNP0C0C:00, PNP0C0D:00
    /sys/bus/acpi/drivers/tiny-power-button/ -> (no devices)
    3/3 suspend/resume cycles OK (systemctl suspend; woken by power
    button and by keyboard). No SIGRTMIN+4.

  6.18.57 (no blacklist):
    button bound to platform device PNP0C0C:00, tiny-power-button
    loaded; 2/2 resumes ended in SIGRTMIN+4, an attempted poweroff
    and a hang.

  6.18.57 with tiny_power_button blacklisted:
    suspend/resume works.

Suggested fix: backport f4203ec64e11 together with 52d864019636, or
revert 38c79dacc806 (and its dependents) from 6.18.y. Note that the same
backport also appears to lose fixed-event power buttons (LNXPWRBN)
without ab06eb920401 ("ACPI: scan: Register platform devices for fixed
event buttons"), reported at
https://github.com/siderolabs/talos/issues/14657

#regzbot introduced: 38c79dacc806

Thanks,Mikkel

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Thorsten Leemhuis]

On 10/21/26 10:35, Mikkel Sejdelin wrote:

> Since 6.18.57, my laptop never comes back from suspend-to-idle: on resume
> init receives SIGRTMIN+4 and starts a poweroff, the display stays off, and
> the machine hangs until it is forced off. 6.18.56 works fine.
> [...]
> Suggested fix: backport f4203ec64e11 together with 52d864019636, or
> revert 38c79dacc806 (and its dependents) from 6.18.y. Note that the same
> backport also appears to lose fixed-event power buttons (LNXPWRBN)
> without ab06eb920401 ("ACPI: scan: Register platform devices for fixed
> event buttons"), reported at
> https://github.com/siderolabs/talos/issues/14657

FWIW, ab06eb9204010c ("ACPI: scan: Register platform devices for fixed
event buttons") is already queued for the next 6.18.y release.

Maybe your request to pick up f4203ec64e1155 ("ACPI: tiny-power-button:
Convert the driver to a platform one") is enough to make the stable team
pick this up for 6.18.y. Ideally you would try if this really fix this;
or have you and I missed this in your mail? Ciao, Thorsten

Sv: Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Mikkel Sejdelin]

On 10/21/26 15:53, Thorsten Leemhuis wrote:
> Maybe your request to pick up f4203ec64e1155 ("ACPI: tiny-power-button:
> Convert the driver to a platform one") is enough to make the stable team
> pick this up for 6.18.y. Ideally you would try if this really fix this;
> or have you and I missed this in your mail?

I had not tested it yet, now I have: f4203ec64e1155 alone on top of
6.18.57 fixes it. It applies cleanly.

6.18.57 + f4203ec64e1155, tiny_power_button loaded (not blacklisted):

  /sys/bus/platform/devices/PNP0C0C:00/driver -> acpi-button
  /sys/bus/platform/drivers/acpi-tiny-power-button/ -> (no devices)

  3/3 suspend/resume cycles OK (lid close, systemctl suspend woken by
  the power button, systemctl suspend woken by the keyboard). No
  SIGRTMIN+4, no poweroff, no hang.

With both drivers on the platform bus they compete for PNP0C0C:00 again and only button binds, as it did in 6.18.56.

So please pick up for 6.18.y:

  f4203ec64e11 ("ACPI: tiny-power-button: Convert the driver to a platform one")

6.18.58 is still affected (no ACPI changes in it).

Thanks,
Mikkel

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Sasha Levin]

> Suggested fix: backport f4203ec64e11 together with 52d864019636, or
> revert 38c79dacc806 (and its dependents) from 6.18.y. Note that the same
> backport also appears to lose fixed-event power buttons (LNXPWRBN)
> without ab06eb920401 ("ACPI: scan: Register platform devices for fixed
> event buttons"), reported at

Queued the tiny-power-button conversion for 6.18, thanks for the report.
The fixed event buttons commit you mention is already queued for 6.18 as
well.

-- 
Thanks,
Sasha

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Sasha Levin]

> Suggested fix: backport f4203ec64e11 together with 52d864019636, or
> revert 38c79dacc806 (and its dependents) from 6.18.y. Note that the same

I have dropped f4203ec64e11 ("ACPI: tiny-power-button: Convert the
driver to a platform one") from the 6.18 queue. It cannot go out without
ab06eb920401 ("ACPI: scan: Register platform devices for fixed event
buttons"): on its own it would break tiny-power-button on systems with a
fixed-hardware power button. Greg dropped ab06eb920401 on October 23,
together with two ACPI resource-overlap patches that broke the 6.18
build, so it is not part of this release either.

-- 
Thanks,
Sasha

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Mikkel Sejdelin]

On Sat, Oct 24, 2026 at 10:26:52 -0400, Sasha Levin wrote:
> I have dropped f4203ec64e11 ("ACPI: tiny-power-button: Convert the
> driver to a platform one") from the 6.18 queue. It cannot go out without
> ab06eb920401 ("ACPI: scan: Register platform devices for fixed event
> buttons")

Now that ab06eb920401 is queued for 6.18 again [1], could f4203ec64e11
be queued with it? ab06eb920401 alone does not fix this report: on my
machine (control-method power button, PNP0C0C) it changes nothing, and
tiny-power-button keeps binding next to button until it is a platform
driver too. 6.18.59 is still affected.

I tested v6.18.58 + ab06eb920401 (with Ting-Han's 2/3 and 3/3) +
f4203ec64e11 on this laptop: platform devices and bindings unchanged
from 6.18.57, acpi-button binds PNP0C0C:00, acpi-tiny-power-button
stays unbound, 3/3 s2idle resumes OK, no SIGRTMIN+4.

Tested-by: Mikkel Sejdelin <mikkel.sejdelin@proton.me>

Thorsten: regzbot has ab06eb920401 as the fix for this report, but it
needs f4203ec64e11 as well:

#regzbot fix: ACPI: tiny-power-button: Convert the driver to a platform one

[1] https://lore.kernel.org/all/20261024105710.593-2-ue081723@gmail.com/

Thanks,
Mikkel

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Thorsten Leemhuis]

On 10/28/26 10:15, Mikkel Sejdelin wrote:
> On Sat, Oct 24, 2026 at 10:26:52 -0400, Sasha Levin wrote:
>> I have dropped f4203ec64e11 ("ACPI: tiny-power-button: Convert the
>> driver to a platform one") from the 6.18 queue. It cannot go out without
>> ab06eb920401 ("ACPI: scan: Register platform devices for fixed event
>> buttons")
> 
> Now that ab06eb920401 is queued for 6.18 again [1], could f4203ec64e11
> be queued with it? ab06eb920401 alone does not fix this report: on my
> machine (control-method power button, PNP0C0C) it changes nothing, and
> tiny-power-button keeps binding next to button until it is a platform
> driver too. 6.18.59 is still affected.
> 
> I tested v6.18.58 + ab06eb920401 (with Ting-Han's 2/3 and 3/3) +
> f4203ec64e11 on this laptop: platform devices and bindings unchanged
> from 6.18.57, acpi-button binds PNP0C0C:00, acpi-tiny-power-button
> stays unbound, 3/3 s2idle resumes OK, no SIGRTMIN+4.
> 
> Tested-by: Mikkel Sejdelin <mikkel.sejdelin@proton.me>
> 
> Thorsten: regzbot has ab06eb920401 as the fix for this report, but it
> needs f4203ec64e11 as well:
> 
> #regzbot fix: ACPI: tiny-power-button: Convert the driver to a platform one
> 
> [1] https://lore.kernel.org/all/20261024105710.593-2-ue081723@gmail.com/
Thx for fixing this up -- and sorry, my fault, got that wrong, the cover
letter from Ting-Han Hou (now CCed) sounded to me like f4203ec64e11
would not be needed anymore.

Ciao, Thorsten

Re: [REGRESSION] 6.18.57: resume from s2idle triggers poweroff and hangs when tiny_power_button is built as a module

[Sasha Levin]

On Wed, Oct 28, 2026 at 09:15:22 +0000, Mikkel Sejdelin wrote:
> Now that ab06eb920401 is queued for 6.18 again [1], could f4203ec64e11
> be queued with it?

Yes. ab06eb920401 stays queued for 6.18, and f4203ec64e11 ("ACPI:
tiny-power-button: Convert the driver to a platform one") is now queued
for 6.18 after it.

> Tested-by: Mikkel Sejdelin <mikkel.sejdelin@proton.me>

Thanks for testing this.

Your stack also included Ting-Han's 2/3 and 3/3. f234fdaae1ca stays
queued, and I added its upstream follow-ups edfaa81d5da5 and
7617cc05df28 as well, so the nested-resource regression (arm-cmn) that
7617cc05df28 fixed upstream does not come along.

-- 
Thanks,
Sasha