On 19 September 2013 18:28, Srivatsa S. Bhat <srivatsa.b...@linux.vnet.ibm.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
