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@gmail.com> 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@mail.gmail.com/#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");

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@kernel.org>:
>
> 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@gmail.com> 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@mail.gmail.com/#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");
>
>
>

On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
<evgeny.sagatov@gmail.com> wrote:
>
> The PC froze when I pressed the power button.

Well, we need to dig more I guess.

> 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

This kind of calls for some investigation.  It should not be less than
scaling_min_freq, even though this looks like a rounding error.

> /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

So with the same patch applied (because I think that the one-policy
configuration is suitable for this platform), please capture the
output of

grep -r . /sys/devices/system/cpu/cpufreq/

switch over to the ondemand governor, wait for some time, capture the
output of the above command again and send both.

Also, please send the output of

grep . /sys/firmware/acpi/interrupts/sci*

acquired after doing all of the above.

You may as well check again if the power button works after switching
to ondemand.

On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> <evgeny.sagatov@gmail.com> wrote:
> >
> > The PC froze when I pressed the power button.
>
> Well, we need to dig more I guess.
>
> > 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
>
> This kind of calls for some investigation.  It should not be less than
> scaling_min_freq, even though this looks like a rounding error.
>
> > /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
>
> So with the same patch applied (because I think that the one-policy
> configuration is suitable for this platform), please capture the
> output of
>
> grep -r . /sys/devices/system/cpu/cpufreq/

Actually, the step above isn't necessary.

> switch over to the ondemand governor,

It is better to reset the cpufreq statistics after switching over to
ondemand by writing 1 to

/sys/devices/system/cpu/cpufreq/policy0/stats/reset

as root.  Then, wait for some time and capture the output of

grep -r . /sys/devices/system/cpu/cpufreq/

just once.

> wait for some time, capture the
> output of the above command again and send both.
>
> Also, please send the output of
>
> grep . /sys/firmware/acpi/interrupts/sci*
>
> acquired after doing all of the above.
>
> You may as well check again if the power button works after switching
> to ondemand.

I noticed that for powersave mode, I'm getting the following values:
cat /proc/cpuinfo | grep MHz
cpu MHz         : 2798.689
cpu MHz         : 1999.659
cpu MHz         : 1999.797
cpu MHz         : 2741.103
Also, there's now no difference in the single-core benchmark between
schedutil, ondemand, powersave and performance modes. The benchmark
always gives a very high result.
This wasn't the case before; the modes had different performance levels.

I switched to ondemand, did a reset and waited a few minutes:
grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
/sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:8000
/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
performance schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/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:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
/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        80
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
     80         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:160
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 397
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 68525
/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:2000000
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

чт, 30 апр. 2026 г. в 13:53, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> > <evgeny.sagatov@gmail.com> wrote:
> > >
> > > The PC froze when I pressed the power button.
> >
> > Well, we need to dig more I guess.
> >
> > > 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
> >
> > This kind of calls for some investigation.  It should not be less than
> > scaling_min_freq, even though this looks like a rounding error.
> >
> > > /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
> >
> > So with the same patch applied (because I think that the one-policy
> > configuration is suitable for this platform), please capture the
> > output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
>
> Actually, the step above isn't necessary.
>
> > switch over to the ondemand governor,
>
> It is better to reset the cpufreq statistics after switching over to
> ondemand by writing 1 to
>
> /sys/devices/system/cpu/cpufreq/policy0/stats/reset
>
> as root.  Then, wait for some time and capture the output of
>
> grep -r . /sys/devices/system/cpu/cpufreq/
>
> just once.
>
> > wait for some time, capture the
> > output of the above command again and send both.
> >
> > Also, please send the output of
> >
> > grep . /sys/firmware/acpi/interrupts/sci*
> >
> > acquired after doing all of the above.
> >
> > You may as well check again if the power button works after switching
> > to ondemand.

On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

> cat /proc/cpuinfo | grep MHz
> cpu MHz         : 2798.689
> cpu MHz         : 1999.659
> cpu MHz         : 1999.797
> cpu MHz         : 2741.103
> Also, there's now no difference in the single-core benchmark between
> schedutil, ondemand, powersave and performance modes. The benchmark
> always gives a very high result.
> This wasn't the case before; the modes had different performance levels.

I would expect schedutil, ondemand and performance to give similar
scores, but for powersave I would expect the score to be lower.

With the same patch applied, can you please switch over to powersave,
reset the stats and then capture the output of

grep -r . /sys/devices/system/cpu/cpufreq/

Also, I'd still like to see the output of

grep . /sys/firmware/acpi/interrupts/sci*

I forgot to say that in ondemand mode, when I pressed the power
button, the PC did not freeze.

чт, 30 апр. 2026 г. в 14:41, Evgeny Sagatov <evgeny.sagatov@gmail.com>:
>
> I noticed that for powersave mode, I'm getting the following values:
> cat /proc/cpuinfo | grep MHz
> cpu MHz         : 2798.689
> cpu MHz         : 1999.659
> cpu MHz         : 1999.797
> cpu MHz         : 2741.103
> Also, there's now no difference in the single-core benchmark between
> schedutil, ondemand, powersave and performance modes. The benchmark
> always gives a very high result.
> This wasn't the case before; the modes had different performance levels.
>
> I switched to ondemand, did a reset and waited a few minutes:
> grep -r . /sys/devices/system/cpu/cpufreq/
> /sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
> /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:8000
> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
> performance schedutil
> /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
> /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:2000000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
> /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        80
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
>      80         0
> /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:160
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 397
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 68525
> /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:2000000
> /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
>
> чт, 30 апр. 2026 г. в 13:53, Rafael J. Wysocki <rafael@kernel.org>:
> >
> > On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> > > <evgeny.sagatov@gmail.com> wrote:
> > > >
> > > > The PC froze when I pressed the power button.
> > >
> > > Well, we need to dig more I guess.
> > >
> > > > 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
> > >
> > > This kind of calls for some investigation.  It should not be less than
> > > scaling_min_freq, even though this looks like a rounding error.
> > >
> > > > /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
> > >
> > > So with the same patch applied (because I think that the one-policy
> > > configuration is suitable for this platform), please capture the
> > > output of
> > >
> > > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > Actually, the step above isn't necessary.
> >
> > > switch over to the ondemand governor,
> >
> > It is better to reset the cpufreq statistics after switching over to
> > ondemand by writing 1 to
> >
> > /sys/devices/system/cpu/cpufreq/policy0/stats/reset
> >
> > as root.  Then, wait for some time and capture the output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > just once.
> >
> > > wait for some time, capture the
> > > output of the above command again and send both.
> > >
> > > Also, please send the output of
> > >
> > > grep . /sys/firmware/acpi/interrupts/sci*
> > >
> > > acquired after doing all of the above.
> > >
> > > You may as well check again if the power button works after switching
> > > to ondemand.

On Thu, Apr 30, 2026 at 1:58 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> I forgot to say that in ondemand mode, when I pressed the power
> button, the PC did not freeze.

OK

I think that's because ondemand changes the CPU frequency 10 times
less frequently than schedutil.

Writing a sufficiently large number to

/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

when schedutil is the cpufreq governor may help, but I actually don't
know how large that number would need to be.

> I guess you mean with the powersave governor.

That's the thing, I get these weird values in powersave mode.

> I would expect schedutil, ondemand and performance to give similar
> scores, but for powersave I would expect the score to be lower.

I did some measurements earlier. I got roughly the same values in
schedutil and performance modes. In ondemand mode, it was 7% lower. In
powersave mode, it was significantly lower, but I don't remember the
exact values.
Now, the values are at their maximum in all modes.

I see that the frequencies change frequently.

cat /proc/cpuinfo | grep MHz
cpu MHz         : 2000.000
cpu MHz         : 2000.000
cpu MHz         : 2673.037
cpu MHz         : 2601.029

But I don't see this reflected in the statistics.

grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:powersave
performance schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:powersave
/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:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
/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         0
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
      0         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:0
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 0
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 8222
/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:2000000
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

grep . /sys/firmware/acpi/interrupts/sci*
/sys/firmware/acpi/interrupts/sci:       0
/sys/firmware/acpi/interrupts/sci_not:       0


I tried this with the previous patch, and the kernel didn't freeze
when I pressed the button.
But with kernel 6.12.74, it doesn't work.
echo 100000 > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

чт, 30 апр. 2026 г. в 17:10, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thu, Apr 30, 2026 at 1:58 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> >
> > I forgot to say that in ondemand mode, when I pressed the power
> > button, the PC did not freeze.
>
> OK
>
> I think that's because ondemand changes the CPU frequency 10 times
> less frequently than schedutil.
>
> Writing a sufficiently large number to
>
> /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us
>
> when schedutil is the cpufreq governor may help, but I actually don't
> know how large that number would need to be.