Messages in this thread |  | | From | Evgeny Sagatov <> | | Date | Fri, 1 May 2026 02:17:48 +0300 | | Subject | Re: 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); > > > >
|  |