Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

I removed the previous patch and installed the new one in kernel 7.0.0.
schedutil - complete freeze, no messages in the log
performance - log message when pressing power button, doesn't reboot
ondemand - log message when pressing power button, doesn't reboot

Log: apr 23 17:40:04 srv kernel: acpi-button LNXPWRBN:00: ACPI button event

чт, 23 апр. 2026 г. в 16:17, Rafael J. Wysocki <rafael@xxxxxxxxxx>:
>
> On Wednesday, April 22, 2026 4:48:41 PM CEST Evgeny Sagatov wrote:
> > > There are two cpufreq governors to choose from.  Have you decided to compile out the other ones on purpose?
> >
> > Powersave is compiled into the stock Debian kernel as a module, so it
> > does not appear in this list.
> >
> > I changed governor to powersave and pressed the power button. The PC
> > shut down normally.
>
> Interesting.
>
> Can you please also check what happens if you change the cpufreq governor
> to "performance" (on all CPUs) before pressing the power button?
>
> The difference is that with the "performance" governor the CPUs will be
> running at the highest frequency.
>
> > ср, 22 апр. 2026 г. в 17:04, Rafael J. Wysocki <rafael@xxxxxxxxxx>:
> > >
> > > On Wed, Apr 22, 2026 at 3:34 PM Evgeny Sagatov <evgeny.sagatov@xxxxxxxxx> wrote:
> > > >
> > > > # grep -r . /sys/devices/system/cpu/cpufreq/
> > > > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
> > > > schedutil
> > >
> > > There are two cpufreq governors to choose from.  Have you decided to
> > > compile out the other ones on purpose?
> > >
> > > It might be useful to compile the powersave governor in and try to
> > > switch over to it (on all CPUs) before pressing the power button
> > > (without any patches applied).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
> > > > 2000000
> > >
> > > The frequency scaling on this CPU is quite limited (only 2 states to
> > > choose from).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088
> > >
> > > Interestingly, this number doesn't match the available choices (maybe
> > > due to a rounding error or similar).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
> > > > grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
> > > > 2834000   2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
> > > >       0       762
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
> > > >     761         0
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
> > > > /sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000
> > >
> > > The fact that acpi-cpufreq is the scaling driver may be related to the
> > > power button issue in principle.
> > >
> > > I'm still going to send you another debug patch for the button driver though.
>
> So the patch is appended.  It causes a message to be printed into the kernel
> log every time the power button is pressed if all goes well, but the system
> will not shut down (it is also not expected to hang).
>
> Please see if that happens with the patch applied (it is a replacement for the
> previous debug patch).  In principle it should work without changing the
> cpufreq governor.
>
> ---
>  drivers/acpi/button.c |   10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -473,14 +473,12 @@ static void acpi_button_notify(acpi_hand
>                                         event, ++button->pushed);
>  }
>
> -static void acpi_button_notify_run(void *data)
> -{
> -       acpi_button_notify(NULL, ACPI_BUTTON_NOTIFY_STATUS, data);
> -}
> -
>  static u32 acpi_button_event(void *data)
>  {
> -       acpi_os_execute(OSL_NOTIFY_HANDLER, acpi_button_notify_run, data);
> +       struct acpi_button *button = data;
> +
> +       dev_info(button->dev, "ACPI button event\n");
> +
>         return ACPI_INTERRUPT_HANDLED;
>  }
>
>
>
>