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 <[email protected]> wrote: > Hi sandeep, > > On Tue, Aug 30, 2011 at 8:40 AM, sandeep kumar > <[email protected]> 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(). > > Maybe try calling might_sleep() instead. > > > 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?? > > It's hard to say. It means that there is a bug somewhere. How > significant it is depends on exactly what the bug is. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > -- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
