Re: PROBLEM: Cpufreq constantly keeps frequency at maximum on 4.5-rc4

[Viresh Kumar <viresh.kumar@linaro.org>]

On 22-02-16, 18:39, Arto Jantunen wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
> 
> > On 21-02-16, 22:33, Arto Jantunen wrote:
> >> I have tested both available governors, and see the same behavior either
> >> way. The kernel I have defaults to performance, I think I'll try
> >> building another one which defaults to powersave to see if that changes
> >> anything (perhaps both governors actually work but it isn't possible to
> >> switch between them at runtime?). The Debian userspace defaults to
> >> ondemand, which doesn't exist for intel_pstate.
> >
> > I took a close look at git log between 4.4 and 4.5-rc1 for intel-pstate and it
> > had only three patches:
> >
> > 157386b6fc14 cpufreq: intel_pstate: Configurable algorithm to get target pstate
> > e70eed2b6454 cpufreq: intel_pstate: Account for non C0 time
> > 63d1d656a523 cpufreq: intel_pstate: Account for IO wait time
> >
> > The first one creates special routines based on the CPU model you have, yours is
> > 94, i.e. 5e, which means we are going to use: core_params in your case. And so
> > you will be using get_target_pstate_use_performance() for .get_target_pstate().
> >
> > The two later patches doesn't make any changes to the working of core_params()
> > and so shouldn't have changed anything for skylake.
> >
> > Anyway, Please trying reverting the above three patches to see if there is a bug
> > somewhere there. So you need to do:
> >
> > git revert 63d1d656a523
> > git revert e70eed2b6454
> > git revert 157386b6fc14
> 
> Thanks. I tried this, and somewhat surprisingly it doesn't change the
> result. I guess we are back to doing a full bisect?

Good. That was kind of what I expected, so no surprise :)

I think bisect wouldn't be that difficult, please try :)

-- 
viresh