Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

The PC froze when I pressed the power button.

grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
      0       844
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
    843         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

ср, 29 апр. 2026 г. в 23:22, Rafael J. Wysocki <rafael@xxxxxxxxxx>:
>
> On Wednesday, April 29, 2026 8:24:02 PM CEST Rafael J. Wysocki wrote:
> > On Tue, Apr 28, 2026 at 11:05 PM Evgeny Sagatov
> > <evgeny.sagatov@xxxxxxxxx> wrote:
> > >
> > > The PC also froze with this patch when I pressed the power button.
> >
> > Which means that the issue is not simply a matter of the lack of
> > synchronization between different I/O space accesses, so most likely
> > the problem lies deeper.
> >
> > Let me summarize what we've learned so far (and expand the CC list somewhat).
> >
> > For those who have not seen the previous discussion, it is at:
> >
> > https://lore.kernel.org/lkml/CAGAxtY2SEkx7OgMgM5ypA8qsBN0h6pcs111VjnhD-5ZGq7Je6Q@xxxxxxxxxxxxxx/#r
> >
> > 1. The issue is basically that the platform locks up completely when
> > the power button is pressed
> >
> > This is reproducible 100% of the time.
> >
> > The power button processing flow is that, if the power button event is
> > enabled in the ACPI PM1_ENABLE register, pressing the button causes
> > the corresponding status bit in the ACPI PM1_STATUS register to be
> > set, which in turn causes an ACPI interrupt (SCI) to trigger (both
> > PM1_STATUS and PM1_ENABLE registers are accessible through the I/O
> > address space).
> >
> > The SCI processing involves reading both the power button status and
> > enable bits and clearing the former if set (this needs to be done or
> > an interrupt storm would start if the status bit was not cleared).
> >
> > We don't actually know which of the steps above specifically causes
> > the platform to lock up, but that doesn't matter too much because all
> > of them are necessary.
> >
> > Clearing the power button enable bit in PM1_ENABLE prevents the issue
> > from occurring (but then the power button obviously doesn't work).
> >
> > 2. The issue only occurs if the schedutil cpufreq governor is used
> >
> > If either the "powersave" or "ondemand" governor is used instead, the
> > issue doesn't appear.
> >
> > Also switching over to a different cpufreq governor (on all CPUs)
> > before pressing the power button makes the issue go away.
> >
> > 3. The issue didn't occur at all before commit e37617c8e53a
> > ("sched/fair: Fix frequency selection for non-invariant case")
> >
> > Reverting the merge that introduced commit e37617c8e53a into the
> > mainline makes the issue go away.
> >
> > 4. The issue occurs regardless of how schedutil invokes the cpufreq
> > driver ("fast switch" vs sugov_deferred_update())
> >
> > 5. The cpufreq driver in question is acpi-cpufreq and it uses a
> > control register located in the I/O address space (the same control
> > register is used for all CPUs)
> >
> > 6. If acpi-cpufreq is not allowed to write into the control register
> > at all, the issue doesn't occur
> >
> > 7. Synchronizing all of the I/O space accesses in the ACPI-related
> > code (via a spinlock), including acpi-cpufreq, doesn't prevent the
> > issue from occurring
> >
> > So overall, it looks like the control register access pattern in
> > acpi-cpufreq that results from schedutil's use of it after commit
> > e37617c8e53a somehow puts the platform into a state in which a power
> > button event causes it to lock up at the hardware level.
> >
> > While there are a couple of things more to check, I'm afraid that
> > there may not be a viable way to address this issue other than
> > replacing the schedutil governor with ondemand on this platform.
>
> Below is one more patch to try.  It should cause acpi-cpufreq to use
> one shared cpufreq policy instead of 4 per-CPU policies which is
> more adequate because the CPUs share one control register.  It should
> also cause acpi-cpufreq to update the control register only on CPU0.
>
> Let's see if this changes the control register access pattern sufficiently
> to work around the power button problem.
>
> In any case, please send the output of
>
> $ grep -r . /sys/devices/system/cpu/cpufreq/
>
> from a kernel with this patch applied.
>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -743,7 +743,7 @@ static int acpi_cpufreq_cpu_init(struct
>         if (result)
>                 goto err_free_mask;
>
> -       policy->shared_type = perf->shared_type;
> +       policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>
>         /*
>          * Will let policy->cpus know about dependency only when software
> @@ -751,9 +751,9 @@ static int acpi_cpufreq_cpu_init(struct
>          */
>         if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
>             policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
> -               cpumask_copy(policy->cpus, perf->shared_cpu_map);
> +               cpumask_copy(policy->cpus, cpu_present_mask);
>         }
> -       cpumask_copy(data->freqdomain_cpus, perf->shared_cpu_map);
> +       cpumask_copy(data->freqdomain_cpus, cpu_present_mask);
>
>  #ifdef CONFIG_SMP
>         dmi_check_system(sw_any_bug_dmi_table);
> @@ -913,7 +913,9 @@ static int acpi_cpufreq_cpu_init(struct
>         data->resume = 1;
>
>         policy->fast_switch_possible = !acpi_pstate_strict &&
> -               !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> +               (!policy_is_shared(policy) ||
> +                policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) &&
> +               perf->control_register.space_id != ACPI_ADR_SPACE_SYSTEM_IO;
>
>         if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
>                 pr_warn(FW_WARN "P-state 0 is not max freq\n");
>
>
>