Hi Dave,
>Maybe try calling might_sleep() instead.
>> Dont know why, might_sleep() is not helping. i put might_sleep in between spin_lock & spin_unlock, it did not work. msleep worked.
>> i found the issue though, as you said they called preempt_disable and forgot to enable it.
>> Thanks for the response.
On Wed, Aug 31, 2011 at 10:53 AM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
Hi sandeep,
Maybe try calling might_sleep() instead.
On Tue, Aug 30, 2011 at 8:40 AM, sandeep kumar
<coolsandyforyou@xxxxxxxxx> wrote:
> Hi Dave,
>>>Maybe the device that was added before this one entered the atomic
>>>context and forgot to leave it.
>>>>>by this you mean to say that, the earlier device which was created, in
>>>>> its probe...
> it took some spin_lock and forgot to release the lock?
>
>
>>>You said that you called in_atomic() from msm_bus_fabric_probe and
>>>that it returned zero. Did you do this immediately before the
>>>mutex_lock call that's complaining?
>>>>> yes,i tested the in_atomic() just before the call of clk_get() which
>>>>> inturn
> calls clk_sys_get() which takes the mutex_lock().
It's hard to say. It means that there is a bug somewhere. How
> My another qn is..
> The message"BUG: sleepin func called ....." is a warning message. it is not
> called by BUG handler.
> So can i neglect it? i mean it is coming only once while in the probe,
> shall this
> lead to lock up s in future??
significant it is depends on exactly what the bug is.
--
--
With regards,
Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
