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@gmail.com> wrote:

Hi sandeep,

On Tue, Aug 30, 2011 at 8:40 AM, sandeep kumar <coolsandyforyou@gmail.com> 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,