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

[Evgeny Sagatov]

dmesg | grep "frequency s"
[    8.622778] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
[    8.622806] cpufreq: CPU0: Fast frequency switching enabled
[    8.622869] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
[    8.622888] cpufreq: CPU1: Fast frequency switching enabled
[    8.622938] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
[    8.622955] cpufreq: CPU2: Fast frequency switching enabled
[    8.623006] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
[    8.623026] cpufreq: CPU3: Fast frequency switching enabled

When I press the power button, a message is displayed:
apr 26 23:40:36 srv kernel: ACPI power button event

The PC does not freeze.
The single core performance benchmark shows good values.

вс, 26 апр. 2026 г. в 17:54, Rafael J. Wysocki <rafael@xxxxxxxxxx>:
>
> On Sun, Apr 26, 2026 at 4:50 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > On Friday, April 24, 2026 11:18:02 PM CEST Evgeny Sagatov wrote:
> > > dmesg | grep "Fast frequency"
> > > Nothing was displayed.
> > >
> > > The PC froze when I pressed the power button. Nothing in the log.
> > >
> > > I applied this patch after deleting all the previous ones. Is this correct?
> >
> > Yes, it is.
> >
> > > I received this message when applying a patch. Perhaps we have
> > > different versions of the source code? I'm using 7.0.0.
> > > patching file drivers/acpi/acpica/evevent.c
> > > patching file drivers/cpufreq/acpi-cpufreq.c
> > > Hunk #1 succeeded at 895 (offset -17 lines).
> > > patching file drivers/cpufreq/cpufreq.c
> >
> > That should be fine.
> >
> > We've switched over schedutil to a different code path and the problem is
> > still there, so it appears to be related to hardware accesses.
> >
> > To test this, please apply the patch below (which is a replacement for the
> > previous patch) and collect the output of
> >
> > $ dmesg | grep ""
>
> This should have been
>
> $ dmesg | grep "frequency scaling"
>
> (pressed "send" too early, sorry about that) but sending a complete
> dmesg log (which would be produced by grepping for an empty string)
> would work either.
>
> > after a fresh boot.  Please let me know what's there.
> >
> > Also, the "Fast frequency switching enabled" messages should be back.
> >
> > Then, check what happens when the power button is pressed (if the system
> > doesn't lock up, a message should be printed to the kernel log every time
> > the power button is pressed).
> >
> > With this patch applied, schedutil will not access hardware in the fast
> > frequency switching path, so the frequency scaling will not actually work
> > (this is roughly equivalent to running the "performance" or "powersave"
> > governor all the time).
> >
> > ---
> >  drivers/acpi/acpica/evevent.c  |    5 +++++
> >  drivers/cpufreq/acpi-cpufreq.c |    6 ++++--
> >  drivers/cpufreq/cpufreq.c      |    1 +
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/acpi/acpica/evevent.c
> > +++ b/drivers/acpi/acpica/evevent.c
> > @@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
> >         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
> >                                       status_register_id, ACPI_CLEAR_STATUS);
> >
> > +       if (event == ACPI_EVENT_POWER_BUTTON) {
> > +               pr_info("ACPI power button event\n");
> > +               return (ACPI_INTERRUPT_HANDLED);
> > +       }
> > +
> >         /*
> >          * Make sure that a handler exists. If not, report an error
> >          * and disable the event to prevent further interrupts.
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
> >                         return next_freq;
> >         }
> >
> > -       data->cpu_freq_write(&perf->control_register,
> > -                            perf->states[next_perf_state].control);
> > +       /*data->cpu_freq_write(&perf->control_register,
> > +                            perf->states[next_perf_state].control);*/
> >         perf->state = next_perf_state;
> >         return next_freq;
> >  }
> > @@ -887,9 +887,11 @@ static int acpi_cpufreq_cpu_init(struct
> >                  * unknown and not detectable via IO ports.
> >                  */
> >                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> > +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> >                 break;
> >         case ACPI_ADR_SPACE_FIXED_HARDWARE:
> >                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> > +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
> >                 break;
> >         default:
> >                 break;
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
> >         if (cpufreq_fast_switch_count >= 0) {
> >                 cpufreq_fast_switch_count++;
> >                 policy->fast_switch_enabled = true;
> > +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
> >         } else {
> >                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
> >                         policy->cpu);
> >
> >
> >
> >