Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Thursday, December 7, 2017 1:51:04 PM CET Meelis Roos wrote:
> > On 06-12-17, 20:21, Meelis Roos wrote:
> > > 3 was not reliable.
> > > 
> > > I created root cron job
> > > @reboot sleep 120; /sbin/reboot
> > > 
> > > and by the evening it was dead again.
> > > 
> > > Will try 5 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, 20 value here.
> 
> I tried
> 
> policy->transition_delay_us = 20;
> 
> and it still hangs on top of mainline.
> 
> What next?

Well, please try to revert the commit you bisected the problem to and see
if that doesn't hang.

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Thursday, December 7, 2017 1:51:04 PM CET Meelis Roos wrote:
> > On 06-12-17, 20:21, Meelis Roos wrote:
> > > 3 was not reliable.
> > > 
> > > I created root cron job
> > > @reboot sleep 120; /sbin/reboot
> > > 
> > > and by the evening it was dead again.
> > > 
> > > Will try 5 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, 20 value here.
> 
> I tried
> 
> policy->transition_delay_us = 20;
> 
> and it still hangs on top of mainline.
> 
> What next?

Well, please try to revert the commit you bisected the problem to and see
if that doesn't hang.

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

I tried

policy->transition_delay_us = 20;

and it still hangs on top of mainline.

What next?


-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

I tried

policy->transition_delay_us = 20;

and it still hangs on top of mainline.

What next?


-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

On 07-12-17, 09:26, Meelis Roos wrote:
> > On 06-12-17, 20:21, Meelis Roos wrote:
> > > 3 was not reliable.
> > > 
> > > I created root cron job
> > > @reboot sleep 120; /sbin/reboot
> > > 
> > > and by the evening it was dead again.
> > > 
> > > Will try 5 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, 20 value here.
> 
> Sorry, I confused 20 vs 2, will test 20.
> 
> But 20 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 20 with or without 
> the other limiting patch?

-- 
viresh

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

On 07-12-17, 09:26, Meelis Roos wrote:
> > On 06-12-17, 20:21, Meelis Roos wrote:
> > > 3 was not reliable.
> > > 
> > > I created root cron job
> > > @reboot sleep 120; /sbin/reboot
> > > 
> > > and by the evening it was dead again.
> > > 
> > > Will try 5 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, 20 value here.
> 
> Sorry, I confused 20 vs 2, will test 20.
> 
> But 20 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 20 with or without 
> the other limiting patch?

-- 
viresh

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

Sorry, I confused 20 vs 2, will test 20.

But 20 was the value before. Shall I test 20 with or without 
the other limiting patch?

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

Sorry, I confused 20 vs 2, will test 20.

But 20 was the value before. Shall I test 20 with or without 
the other limiting patch?

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

2 was the first one tested, after it was unreliable, I tested 3 
and that was unreliable too.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 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, 20 value here.

2 was the first one tested, after it was unreliable, I tested 3 
and that was unreliable too.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

On 06-12-17, 20:21, Meelis Roos wrote:
> 3 was not reliable.
> 
> I created root cron job
> @reboot sleep 120; /sbin/reboot
> 
> and by the evening it was dead again.
> 
> Will try 5 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, 20 value here.

-- 
viresh

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

On 06-12-17, 20:21, Meelis Roos wrote:
> 3 was not reliable.
> 
> I created root cron job
> @reboot sleep 120; /sbin/reboot
> 
> and by the evening it was dead again.
> 
> Will try 5 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, 20 value here.

-- 
viresh

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> >> > 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 = 20;/* nsec */
> >> > +   policy->transition_delay_us = 2;/* 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 3, say, and see if that's reliable?

3 was not reliable.

I created root cron job
@reboot sleep 120; /sbin/reboot

and by the evening it was dead again.

Will try 5 tomorrow.

-- 
Meelis Roos (mr...@linux.ee

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> >> > 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 = 20;/* nsec */
> >> > +   policy->transition_delay_us = 2;/* 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 3, say, and see if that's reliable?

3 was not reliable.

I created root cron job
@reboot sleep 120; /sbin/reboot

and by the evening it was dead again.

Will try 5 tomorrow.

-- 
Meelis Roos (mr...@linux.ee

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Tue, Dec 5, 2017 at 9:54 AM, Meelis Roos  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+  # 4.14+
>> > Reported-by: Meelis Roos 
>> > Suggested-by: Rafael J. Wysocki 
>> > Signed-off-by: Viresh Kumar 
>> > ---
>> >  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 = 20;/* nsec */
>> > +   policy->transition_delay_us = 2;/* 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 3, say, and see if that's reliable?

Thanks,
Rafael

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Tue, Dec 5, 2017 at 9:54 AM, Meelis Roos  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+  # 4.14+
>> > Reported-by: Meelis Roos 
>> > Suggested-by: Rafael J. Wysocki 
>> > Signed-off-by: Viresh Kumar 
>> > ---
>> >  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 = 20;/* nsec */
>> > +   policy->transition_delay_us = 2;/* 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 3, say, and see if that's reliable?

Thanks,
Rafael

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 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+  # 4.14+
> > Reported-by: Meelis Roos 
> > Suggested-by: Rafael J. Wysocki 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  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 = 20;/* nsec */
> > +   policy->transition_delay_us = 2;/* 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 (mr...@ut.ee)  http://www.cs.ut.ee/~mroos/

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 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+  # 4.14+
> > Reported-by: Meelis Roos 
> > Suggested-by: Rafael J. Wysocki 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  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 = 20;/* nsec */
> > +   policy->transition_delay_us = 2;/* 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 (mr...@ut.ee)  http://www.cs.ut.ee/~mroos/

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> 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+  # 4.14+
> Reported-by: Meelis Roos 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Viresh Kumar 
> ---
>  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 = 20;/* nsec */
> + policy->transition_delay_us = 2;/* usec */
>  
>   return cpufreq_table_validate_and_show(policy, longhaul_table);
>  }

This patch also works on my EPIA-M board - tested 10+ times.

Sorry it took so long to test, it was a remote computer.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> 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+  # 4.14+
> Reported-by: Meelis Roos 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Viresh Kumar 
> ---
>  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 = 20;/* nsec */
> + policy->transition_delay_us = 2;/* usec */
>  
>   return cpufreq_table_validate_and_show(policy, longhaul_table);
>  }

This patch also works on my EPIA-M board - tested 10+ times.

Sorry it took so long to test, it was a remote computer.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Wednesday, November 29, 2017 7:59:27 AM CET Meelis Roos wrote:
> > > 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 = 20;/* nsec */
> > > +   policy->transition_delay_us = 2;/* usec */
> > >
> > > return cpufreq_table_validate_and_show(policy, longhaul_table);
> > >  }
> > > --
> > 
> > Meelis, please check if this fixes the shutdown issue you have
> > reported recently.
> 
> Yes, but not today - hopefully tomorrow.

Any news?

I'd like to push the fix for 4.15 shortly if it works for you (I don't
see why it wouldn't work, but still I'd prefer it to be actually tested).

Thanks,
Rafael

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Wednesday, November 29, 2017 7:59:27 AM CET Meelis Roos wrote:
> > > 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 = 20;/* nsec */
> > > +   policy->transition_delay_us = 2;/* usec */
> > >
> > > return cpufreq_table_validate_and_show(policy, longhaul_table);
> > >  }
> > > --
> > 
> > Meelis, please check if this fixes the shutdown issue you have
> > reported recently.
> 
> Yes, but not today - hopefully tomorrow.

Any news?

I'd like to push the fix for 4.15 shortly if it works for you (I don't
see why it wouldn't work, but still I'd prefer it to be actually tested).

Thanks,
Rafael

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 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 = 20;/* nsec */
> > +   policy->transition_delay_us = 2;/* usec */
> >
> > return cpufreq_table_validate_and_show(policy, longhaul_table);
> >  }
> > --
> 
> Meelis, please check if this fixes the shutdown issue you have
> reported recently.

Yes, but not today - hopefully tomorrow.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > 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 = 20;/* nsec */
> > +   policy->transition_delay_us = 2;/* usec */
> >
> > return cpufreq_table_validate_and_show(policy, longhaul_table);
> >  }
> > --
> 
> Meelis, please check if this fixes the shutdown issue you have
> reported recently.

Yes, but not today - hopefully tomorrow.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Tue, Nov 28, 2017 at 4:11 AM, Viresh Kumar  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+  # 4.14+
> Reported-by: Meelis Roos 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Viresh Kumar 
> ---
>  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 = 20;/* nsec */
> +   policy->transition_delay_us = 2;/* usec */
>
> return cpufreq_table_validate_and_show(policy, longhaul_table);
>  }
> --

Meelis, please check if this fixes the shutdown issue you have
reported recently.

Thanks,
Rafael

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Rafael J. Wysocki]

On Tue, Nov 28, 2017 at 4:11 AM, Viresh Kumar  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+  # 4.14+
> Reported-by: Meelis Roos 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Viresh Kumar 
> ---
>  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 = 20;/* nsec */
> +   policy->transition_delay_us = 2;/* usec */
>
> return cpufreq_table_validate_and_show(policy, longhaul_table);
>  }
> --

Meelis, please check if this fixes the shutdown issue you have
reported recently.

Thanks,
Rafael

[PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

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+  # 4.14+
Reported-by: Meelis Roos 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
---
 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 = 20;/* nsec */
+   policy->transition_delay_us = 2;/* usec */
 
return cpufreq_table_validate_and_show(policy, longhaul_table);
 }
-- 
2.15.0.194.g9af6a3dea062

[PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Viresh Kumar]

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+  # 4.14+
Reported-by: Meelis Roos 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
---
 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 = 20;/* nsec */
+   policy->transition_delay_us = 2;/* usec */
 
return cpufreq_table_validate_and_show(policy, longhaul_table);
 }
-- 
2.15.0.194.g9af6a3dea062