On 04/29/2014 01:34 PM, Viresh Kumar wrote:
> On 29 April 2014 13:05, Srivatsa S. Bhat
> wrote:
>> On 04/29/2014 12:19 PM, Viresh Kumar wrote:
>>> + WARN_ON(!(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION)
>>> && (current == policy->transition_task));
>>>
On 29 April 2014 13:05, Srivatsa S. Bhat
wrote:
> On 04/29/2014 12:19 PM, Viresh Kumar wrote:
>> + WARN_ON(!(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION)
>> && (current == policy->transition_task));
>>
>> which you already mentioned.
>
> Yeah, I think we
On 04/29/2014 12:19 PM, Viresh Kumar wrote:
> On 29 April 2014 11:46, Srivatsa S. Bhat
> wrote:
>> Yes, I'm aware that this corner case doesn't work well with my debug
>
> Don't know if its a corner case, it may be the most obvious case for
> some :)
>
Yeah, it could be.
>> patch. I tried to
On 29 April 2014 11:46, Srivatsa S. Bhat
wrote:
> Yes, I'm aware that this corner case doesn't work well with my debug
Don't know if its a corner case, it may be the most obvious case for
some :)
> patch. I tried to avoid this but couldn't think of any solution.
The problem is not that it
On 04/29/2014 10:25 AM, Viresh Kumar wrote:
> On 29 April 2014 10:21, Viresh Kumar wrote:
>> Nice effort.
>>
>> On 29 April 2014 00:25, Srivatsa S. Bhat
>> wrote:
>>> Now all such drivers have been fixed, but debugging this issue was not
>>> very straight-forward (even lockdep didn't catch
On 04/29/2014 10:21 AM, Viresh Kumar wrote:
> Nice effort.
>
Thanks! :-)
> On 29 April 2014 00:25, Srivatsa S. Bhat
> wrote:
>> Now all such drivers have been fixed, but debugging this issue was not
>> very straight-forward (even lockdep didn't catch this). So let us add a
>> debug
On 04/29/2014 10:21 AM, Viresh Kumar wrote:
Nice effort.
Thanks! :-)
On 29 April 2014 00:25, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So let us
On 04/29/2014 10:25 AM, Viresh Kumar wrote:
On 29 April 2014 10:21, Viresh Kumar viresh.ku...@linaro.org wrote:
Nice effort.
On 29 April 2014 00:25, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Now all such drivers have been fixed, but debugging this issue was not
very
On 29 April 2014 11:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Yes, I'm aware that this corner case doesn't work well with my debug
Don't know if its a corner case, it may be the most obvious case for
some :)
patch. I tried to avoid this but couldn't think of any solution.
On 04/29/2014 12:19 PM, Viresh Kumar wrote:
On 29 April 2014 11:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Yes, I'm aware that this corner case doesn't work well with my debug
Don't know if its a corner case, it may be the most obvious case for
some :)
Yeah, it could be.
On 29 April 2014 13:05, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 04/29/2014 12:19 PM, Viresh Kumar wrote:
+ WARN_ON(!(cpufreq_driver-flags CPUFREQ_ASYNC_NOTIFICATION)
(current == policy-transition_task));
which you already mentioned.
On 04/29/2014 01:34 PM, Viresh Kumar wrote:
On 29 April 2014 13:05, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 04/29/2014 12:19 PM, Viresh Kumar wrote:
+ WARN_ON(!(cpufreq_driver-flags CPUFREQ_ASYNC_NOTIFICATION)
(current ==
On 29 April 2014 10:21, Viresh Kumar wrote:
> Nice effort.
>
> On 29 April 2014 00:25, Srivatsa S. Bhat
> wrote:
>> Now all such drivers have been fixed, but debugging this issue was not
>> very straight-forward (even lockdep didn't catch this). So let us add a
>> debug infrastructure to the
Nice effort.
On 29 April 2014 00:25, Srivatsa S. Bhat
wrote:
> Now all such drivers have been fixed, but debugging this issue was not
> very straight-forward (even lockdep didn't catch this). So let us add a
> debug infrastructure to the cpufreq core to catch such issues more easily
> in the
Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes
Some cpufreq drivers were redundantly invoking the _begin() and _end()
APIs around frequency transitions, and this double invocation (one from
the cpufreq core and the other from the cpufreq driver) used to result
in a self-deadlock, leading to system hangs during boot. (The _begin()
API makes
Nice effort.
On 29 April 2014 00:25, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So let us add a
debug infrastructure to the cpufreq core to catch such
On 29 April 2014 10:21, Viresh Kumar viresh.ku...@linaro.org wrote:
Nice effort.
On 29 April 2014 00:25, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Now all such drivers have been fixed, but debugging this issue was not
very straight-forward (even lockdep didn't catch this). So
18 matches
Mail list logo
