On Tue, Nov 19, 2019 at 3:35 PM Doug Smythies <dsmythies@xxxxxxxxx> wrote: > > On 2019.11.17 08:13 Doug Smythies wrote: > > On 2019.11.16 23:35 Doug Smythies wrote: > > >> Hi Rafael, > >> > >> Not sure, but I think it is this one that > >> causes complaining when I try to set the > >> intel_pstate driver to passive mode. > >> I started from active mode, powersave governor, > >> no HWP. > >> > >> Kernel: 5.4-rc7 > >> > >> I did not go back and try previous 5.4 RCs. > > After looking at the git tags for this patch, > I tried kernel 5.4-rc2, which was the closest > Kernel I had to before the patch set was added. > It worked fine, as expected. > > >> I did try kernel 5.3-rc8, because I already had > >> it installed, and it worked fine. > >> > >> I use a script (for years), run as sudo: > >> > >> doug@s15:~/temp$ cat set_cpu_passive > >> #! /bin/bash > >> cat /sys/devices/system/cpu/intel_pstate/status > >> echo passive > /sys/devices/system/cpu/intel_pstate/status > >> cat /sys/devices/system/cpu/intel_pstate/status > >> > >> And I get this (very small excerpt): > >> > >> freq_qos_add_request() called for active request > >> WARNING: CPU: 1 PID: 2758 at kernel/power/qos.c:763 freq_qos_add_request+0x4c/0xa0 > >> CPU: 1 PID: 2758 Comm: set_cpu_passive Not tainted 5.4.0-rc7-stock #727 > >> Failed to add freq constraint for CPU0 (-22) > >> > >> freq_qos_add_request() called for active request > >> WARNING: CPU: 1 PID: 2758 at kernel/power/qos.c:763 freq_qos_add_request+0x4c/0xa0 > >> CPU: 1 PID: 2758 Comm: set_cpu_passive Tainted: G W 5.4.0-rc7-stock #727 > >> Failed to add freq constraint for CPU1 (-22) > > Updated summary of previous emails: > This patch or patch set breaks the after boot > ability to change CPU frequency scaling drivers. > > Using a workaround of booting with > "intel_pstate=passive" seems to prevent the errors. > > Changing between the intel_pstate and intel_cpufreq drivers > (i.e. between active and passive modes) > after boot, either way, causes the errors. i.e. > > Failed to add freq constraint for CPU7 (-22) > (2 per CPU per attempt) These messages come from acpi_processor_ppc_init() and acpi_thermal_cpufreq_init(), AFAICS, which are invoked by acpi_processor_notifier() and that is invoked by the blocking_notifier_call_chain() in cpufreq_online() which tirggers for new policies after adding the max freq QoS request to policy->constraints. The requests added by them should be removed by acpi_processor_ppc_exit() and acpi_thermal_cpufreq_exit(), respectively, invoked by the blocking_notifier_call_chain() in cpufreq_policy_free(), but it looks like that doesn't happen. However, I now also see that freq_qos_remove_request() doesn't clear the qos field in req which is should do, so freq_qos_add_request() will complain and fail if the object pointed to by req is passed to it again. I'll send a patch to test for this later today.
