| Message ID | ed89c17b60d7183144ab4ac4b125fbed373fe670.1511838689.git.viresh.kumar@linaro.org |
|---|---|
| State | Accepted |
| Commit | 1d0d064307cbfd8546841f6e9d94d02c55e45e1e |
| Headers | show |
| Series | cpufreq: longhaul: Set transition_delay_us to 20 ms | expand |
> > The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay > > value to 10 ms") caused a regression on EPIA-M min-ITX computer where > > shutdown or reboot hangs occasionally with a print message like: > > > > longhaul: Warning: Timeout while waiting for idle PCI bus > > cpufreq: __target_index: Failed to change cpu frequency: -16 > > > > This probably happens because the cpufreq governor tries to change the > > frequency of the CPU faster than allowed by the hardware. > > > > With the above commit, the default transition delay comes to 10 ms for a > > transition_latency of 200 us. Set the default transition delay to 20 ms > > directly to fix this regression. > > > > Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") > > Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ > > Reported-by: Meelis Roos <mroos@linux.ee> > > Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > --- > > drivers/cpufreq/longhaul.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c > > index c46a12df40dd..56eafcb07859 100644 > > --- a/drivers/cpufreq/longhaul.c > > +++ b/drivers/cpufreq/longhaul.c > > @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) > > if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) > > longhaul_setup_voltagescaling(); > > > > - policy->cpuinfo.transition_latency = 200000; /* nsec */ > > + policy->transition_delay_us = 20000; /* usec */ > > > > return cpufreq_table_validate_and_show(policy, longhaul_table); > > } > > This patch also works on my EPIA-M board - tested 10+ times. An on the last try just after sending the mail, it hung again in the same way as before - so maybe 20 is on the edge of being good. -- Meelis Roos (mroos@ut.ee) http://www.cs.ut.ee/~mroos/
On Tue, Dec 5, 2017 at 9:54 AM, Meelis Roos <mroos@ut.ee> wrote: >> > The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay >> > value to 10 ms") caused a regression on EPIA-M min-ITX computer where >> > shutdown or reboot hangs occasionally with a print message like: >> > >> > longhaul: Warning: Timeout while waiting for idle PCI bus >> > cpufreq: __target_index: Failed to change cpu frequency: -16 >> > >> > This probably happens because the cpufreq governor tries to change the >> > frequency of the CPU faster than allowed by the hardware. >> > >> > With the above commit, the default transition delay comes to 10 ms for a >> > transition_latency of 200 us. Set the default transition delay to 20 ms >> > directly to fix this regression. >> > >> > Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") >> > Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ >> > Reported-by: Meelis Roos <mroos@linux.ee> >> > Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net> >> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >> > --- >> > drivers/cpufreq/longhaul.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c >> > index c46a12df40dd..56eafcb07859 100644 >> > --- a/drivers/cpufreq/longhaul.c >> > +++ b/drivers/cpufreq/longhaul.c >> > @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) >> > if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) >> > longhaul_setup_voltagescaling(); >> > >> > - policy->cpuinfo.transition_latency = 200000; /* nsec */ >> > + policy->transition_delay_us = 20000; /* usec */ >> > >> > return cpufreq_table_validate_and_show(policy, longhaul_table); >> > } >> >> This patch also works on my EPIA-M board - tested 10+ times. > > An on the last try just after sending the mail, it hung again in the > same way as before - so maybe 20 is on the edge of being good. OK, so can you please try to modify the patch to set transition_delay_us to 30000, say, and see if that's reliable? Thanks, Rafael
> >> > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c > >> > index c46a12df40dd..56eafcb07859 100644 > >> > --- a/drivers/cpufreq/longhaul.c > >> > +++ b/drivers/cpufreq/longhaul.c > >> > @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) > >> > if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) > >> > longhaul_setup_voltagescaling(); > >> > > >> > - policy->cpuinfo.transition_latency = 200000; /* nsec */ > >> > + policy->transition_delay_us = 20000; /* usec */ > >> > > >> > return cpufreq_table_validate_and_show(policy, longhaul_table); > >> > } > >> > >> This patch also works on my EPIA-M board - tested 10+ times. > > > > An on the last try just after sending the mail, it hung again in the > > same way as before - so maybe 20 is on the edge of being good. > > OK, so can you please try to modify the patch to set > transition_delay_us to 30000, say, and see if that's reliable? 30000 was not reliable. I created root cron job @reboot sleep 120; /sbin/reboot and by the evening it was dead again. Will try 50000 tomorrow. -- Meelis Roos (mroos@linux.ee
On 06-12-17, 20:21, Meelis Roos wrote: > 30000 was not reliable. > > I created root cron job > @reboot sleep 120; /sbin/reboot > > and by the evening it was dead again. > > Will try 50000 tomorrow. Lets make it similar to what it was before my original patch modified it, to avoid all corner cases. Please test against 200 ms, 200000 value here. -- viresh
> On 06-12-17, 20:21, Meelis Roos wrote: > > 30000 was not reliable. > > > > I created root cron job > > @reboot sleep 120; /sbin/reboot > > > > and by the evening it was dead again. > > > > Will try 50000 tomorrow. > > Lets make it similar to what it was before my original patch modified > it, to avoid all corner cases. > > Please test against 200 ms, 200000 value here. Sorry, I confused 200000 vs 20000, will test 200000. But 200000 was the value before. Shall I test 200000 with or without the other limiting patch? -- Meelis Roos (mroos@linux.ee)
On 07-12-17, 09:26, Meelis Roos wrote: > > On 06-12-17, 20:21, Meelis Roos wrote: > > > 30000 was not reliable. > > > > > > I created root cron job > > > @reboot sleep 120; /sbin/reboot > > > > > > and by the evening it was dead again. > > > > > > Will try 50000 tomorrow. > > > > Lets make it similar to what it was before my original patch modified > > it, to avoid all corner cases. > > > > Please test against 200 ms, 200000 value here. > > Sorry, I confused 200000 vs 20000, will test 200000. > > But 200000 was the value before. It was value of a different variable (transition_latency) at that time. Just set transition_delay_us in my recent patch as 200,000 and apply that over mainline. I will resend the patch in the mean time as well. > Shall I test 200000 with or without > the other limiting patch? -- viresh
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c index c46a12df40dd..56eafcb07859 100644 --- a/drivers/cpufreq/longhaul.c +++ b/drivers/cpufreq/longhaul.c @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) longhaul_setup_voltagescaling(); - policy->cpuinfo.transition_latency = 200000; /* nsec */ + policy->transition_delay_us = 20000; /* usec */ return cpufreq_table_validate_and_show(policy, longhaul_table); }
The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") caused a regression on EPIA-M min-ITX computer where shutdown or reboot hangs occasionally with a print message like: longhaul: Warning: Timeout while waiting for idle PCI bus cpufreq: __target_index: Failed to change cpu frequency: -16 This probably happens because the cpufreq governor tries to change the frequency of the CPU faster than allowed by the hardware. With the above commit, the default transition delay comes to 10 ms for a transition_latency of 200 us. Set the default transition delay to 20 ms directly to fix this regression. Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ Reported-by: Meelis Roos <mroos@linux.ee> Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/cpufreq/longhaul.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.15.0.194.g9af6a3dea062