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

From: Rafael J. Wysocki

Date: Thu Apr 30 2026 - 10:42:20 EST


On Thursday, April 30, 2026 3:57:41 PM CEST Rafael J. Wysocki wrote:
> On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@xxxxxxxxx> 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*

Additionally, please remove all of the debug patches sent so far, apply
the one below and send a dmesg boot log.

I want to check if all of the CPUs use the same control values when
they write to the frequency scaling control register.

---
drivers/cpufreq/acpi-cpufreq.c | 12 +++++++++---
drivers/cpufreq/cpufreq.c | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -887,9 +887,14 @@ 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);
+ pr_info("CPU%u: frequency scaling control address: %llu, bit width: %u\n",
+ cpu, perf->control_register.address,
+ perf->control_register.bit_width);
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;
@@ -898,13 +903,14 @@ static int acpi_cpufreq_cpu_init(struct
/* notify BIOS that we exist */
acpi_processor_notify_smm(THIS_MODULE);

- pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
+ pr_info("CPU%u - ACPI performance management activated.\n", cpu);
for (i = 0; i < perf->state_count; i++)
- pr_debug(" %cP%d: %d MHz, %d mW, %d uS\n",
+ pr_info(" %cP%d: %d MHz, %d mW, %d uS, %u\n",
(i == perf->state ? '*' : ' '), i,
(u32) perf->states[i].core_frequency,
(u32) perf->states[i].power,
- (u32) perf->states[i].transition_latency);
+ (u32) perf->states[i].transition_latency,
+ (u32) perf->states[i].control);

/*
* the first call to ->target() should result in us actually
--- 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);