Re: Regression on cpufreq in v3.12-rc1

[Viresh Kumar]

On 19 September 2013 18:28, Srivatsa S. Bhat
<srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote:
> On 09/19/2013 06:25 PM, Linus Walleij wrote:

>> The problem is not what it returns, the system seems to survive no matter
>> whether it returns 0 or 17 or whatever.
>>
>
> Of course. What I intended to say was that I don't recall recent kernels
> returning _anything_ on !policy. So there wasn't any sudden change in _that_
> piece of code, AFAIR.
>
>> The problem is that sometimes in the v3.12 kernel cycle we got a
>> BUG() crash instead of some random value back for calling early.
>>
>
> Yep, and that's most likely due to some change in ordering of calls somewhere,
> which makes calls to lock_policy_rwsem_read() before it is safe to do so,
> rather than anything related to how lock_policy_rwsem_read() handles the call.

I don't see any problem in the order things are called from both the places
where you got the crash from.. Because cpufreq driver is registered with
arch_initcall() and both the crash locations gets initialized after that..

I believe the problem is, cpufreq driver failed to register for some reason
and so we are getting this problem...

Can you please confirm if cpufreq driver failed to register or not?

And, I have another solution in mind for getting this problem fixed,
will get that to you by then..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/