lkml.org 
[lkml]   [2026]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Pressing the power button causes the device to freeze completely (schedutil involved)
Rafael,

I'm leaving on vacation today. I'll be able to conduct new checks
starting May 17th.

Thanks for helping with resolving the issue!

чт, 30 апр. 2026 г. в 17:42, 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);
>
>
>
>

\
 
 \ /
  Last update: 2026-05-01 01:19    [W:0.090 / U:9.290 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog