On Mon, Jul 8, 2019 at 5:05 AM Viresh Kumar <viresh.ku...@linaro.org> wrote: > > On 06-07-19, 22:30, Pavel Machek wrote: > > Hi! > > > > > Anyway, if 5.2-rc7 is OK, something in this branch causes the problem > > > to happen for you. > > > > > > I would try > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=f012a132824fc870b90980540f727c76fc72e244 > > > > > > to narrow down the scope somewhat. > > I couldn't find the original mail, what exactly is the problem with > suspend in your case ?
Something unusual: https://lore.kernel.org/linux-pm/20190706190123.GA11603@amd/T/#mca22dd7c1e8836e9253702df9f56a68ab65192a4 > > Bisect says: > > > > 572542c81dec533b7dd3778ea9f5949a00595f68 is the first bad commit > > Author: Viresh Kumar <viresh.ku...@linaro.org> > > > > cpufreq: Register notifiers with the PM QoS framework > > > > This registers the notifiers for min/max frequency constraints > > with the > > > > Reviewed-by: Matthias Kaehlcke <m...@chromium.org> > > Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> > > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> > > > > Unfortunately, it does not revert cleanly: > > I tried following on my ARM board (both single policy and multiple > policy configurations): > > rtcwake --seconds 5 -v -m mem > > And everything worked as expected. Please make sure the top commit of > my series in pm/linux-next is, some issues were fixed on Friday: > > 0a811974f3f7 cpufreq: Add QoS requests for userspace constraints Pavel has tested the latest version of the patch series AFAICS. The locking added by the commit in question to refresh_frequency_limits() requires an update of cpufreq_update_policy(), or it will deadlock in there because of the lock acquired by cpufreq_cpu_get() if I haven't missed anything.
