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

["Rafael J. Wysocki" <rafael@kernel.org>]

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@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*

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);