BUG: sleeping function called from invalid context

BUG: sleeping function called from invalid context

[sandeep kumar]

Hi all,
I am working on android, linux kernel version: 2.6.35.11

I am getting this following error message. I know it occurs when u call a
sleeping function in atomic context.
As far as i knew the entire stack of functions,nothing is atomic
context(these are standard platform dev add functions...)

Now i want to know these things..
1) Is there any method to know, when and where this atomic context started?
           (i put a log in the "msm_bus_fabric_probe" function, to check
whether it is atomic or not using "in_atomic()"..it is giving '0', and also
i read that in_atomic wont always work well in all cases in the header file)

2) Can we neglect this warning, is it very important? because lot of similer
cases,(where "clk_get_sys" is called)
are working fine. only this thing is showing warning message. can we
overlook this?

pls tell me



[    0.267394] BUG: sleeping function called from invalid context at
/home/sandeep_CELOX_NTT/android/kernel/kernel/mutex.c:94
<3>[    0.267455] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper
<4>[    0.267517] [<c01076a0>] (unwind_backtrace+0x0/0x164) from
[<c07233f0>] (mutex_lock+0x18/0x38)
<4>[    0.267578] [<c07233f0>] (mutex_lock+0x18/0x38) from [<c010e5dc>]
(clk_get_sys+0x2c/0xe4)
<4>[    0.267608] [<c010e5dc>] (clk_get_sys+0x2c/0xe4) from [<c01869b4>]
(msm_bus_fabric_probe+0x630/0x818)
<4>[    0.267639] [<c01869b4>] (msm_bus_fabric_probe+0x630/0x818) from
[<c0417b2c>] (platform_drv_probe+0x18/0x1c)
<4>[    0.267669] [<c0417b2c>] (platform_drv_probe+0x18/0x1c) from
[<c0416788>] (driver_probe_device+0x19c/0x34c)
<4>[    0.267730] [<c0416788>] (driver_probe_device+0x19c/0x34c) from
[<c04159c0>] (bus_for_each_drv+0x48/0x84)
<4>[    0.267761] [<c04159c0>] (bus_for_each_drv+0x48/0x84) from
[<c0416a84>] (device_attach+0x64/0x88)
<4>[    0.267791] [<c0416a84>] (device_attach+0x64/0x88) from [<c0415788>]
(bus_probe_device+0x24/0x40)
<4>[    0.267822] [<c0415788>] (bus_probe_device+0x24/0x40) from
[<c04139a0>] (device_add+0x39c/0x52c)
<4>[    0.267852] [<c04139a0>] (device_add+0x39c/0x52c) from [<c0418158>]
(platform_device_add+0x16c/0x1e8)
<4>[    0.267883] [<c0418158>] (platform_device_add+0x16c/0x1e8) from
[<c0418498>] (platform_add_devices+0x1c/0x60)
<4>[    0.267913] [<c0418498>] (platform_add_devices+0x1c/0x60) from
[<c00147d4>] (msm8x60_init+0x378/0x14a4)

-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110830/c249636f/attachment.html 

BUG: sleeping function called from invalid context

[Dave Hylands]

Hi sandeep,

On Tue, Aug 30, 2011 at 6:28 AM, sandeep kumar
<coolsandyforyou@gmail.com> wrote:
> Hi all,
> I am working on android, linux kernel version: 2.6.35.11
>
> I am getting this following error message. I know it occurs when u call a
> sleeping function in atomic context.
> As far as i knew the entire stack of functions,nothing is atomic
> context(these are standard platform dev add functions...)
>
> Now i want to know these things..
> 1) Is there any method to know, when and where?this atomic context started?
> ?????????? (i put a log in the "msm_bus_fabric_probe"?function, to check
> whether it is?atomic or not using "in_atomic()"..it is giving '0', and also
> i read that in_atomic wont always work well in all cases in the header file)
>
> 2) Can we neglect this warning, is it very important? because lot of similer
> cases,(where "clk_get_sys" is called)
> are working fine. only this thing is showing warning message. can we
> overlook this?

It's inidicative  of a bug in the code somewhere. It may be unrelated
to the backtrace. For example, this was detected while adding devices.
Maybe the device that was added before this one entered the atomic
context and forgot to leave it.

The error seems to indicate that you're in an atomic context but that
interrupts are enabled, which would imply that preemption has been
disabled.

Perhaps you can call might_sleep() (which is what mutex_lock is
calling) to see if the BUG triggers at one of the might_sleep calls
that you added.

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?

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

BUG: sleeping function called from invalid context

[sandeep kumar]

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110831/9fd41e75/attachment.html 

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Thu, Nov 24, 2011 at 10:29:09AM +0000, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2011 at 10:05:14AM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> > > On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > > > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > > > today - the clk framework is totally irrelevant as far as this goes.
> > > > I think doing the clk_prepare seperation and converting to the clk
> > > > framework in one step will be easier.
> > > 
> > > From a point of view of being able to separate the changes so there isn't
> > > a flag day, you're wrong.  clk_prepare() is already present in the kernel
> > > as dummy functions, and all you need to do at this point is arrange for
> > > the drivers to make the appropriate calls.  There's no need to write one
> > > line of code behind clk_prepare() at the current time.
> > Yeah, but adding clk_prepare to the serial driver doesn't help me to get
> > rid of the BUG reported in this thread without giving it some meaning in
> > the platform, right?
Note that I wrote that in reply to you saying "There's no need to write
one line of code behind clk_prepare() at the current time.".

> So, let's be honest about why this bug isn't being fixed then.  Your
> attitude to this problem is ignore it and to do nothing, rather than
> trying to fix it via a perfectly good transition path provided for
> you.
I don't think the mxs clock code needs a transition. I guess it will be
mostly reimplemented when the clk framework is settled. And I consider
it quite normal to live with code that is not optimal because there are
bigger changes in the queue that would make fixing the current code
useless. 
 
> Okay, now we can see clearly why the bug is still there.  Thanks.
> 
> Given such an attitude, remind me why I should care whether iMX breaks
> while we do the consolidation and cleanup work to core code, such as
> the recent restart changes.
There are several active contributors to i.MX that invest much time to
adapt i.MX to the current changes. Be it Shawn who does much DT stuff,
Sascha who proposed things for the clk framework or Richard who
converted i.MX5x to the the latest clk framework patches. That's why you
should care. And that is independant of me not doing much for i.MX
during the last few cycles.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Thu, Nov 24, 2011 at 10:05:14AM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> > On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > > today - the clk framework is totally irrelevant as far as this goes.
> > > I think doing the clk_prepare seperation and converting to the clk
> > > framework in one step will be easier.
> > 
> > From a point of view of being able to separate the changes so there isn't
> > a flag day, you're wrong.  clk_prepare() is already present in the kernel
> > as dummy functions, and all you need to do at this point is arrange for
> > the drivers to make the appropriate calls.  There's no need to write one
> > line of code behind clk_prepare() at the current time.
> Yeah, but adding clk_prepare to the serial driver doesn't help me to get
> rid of the BUG reported in this thread without giving it some meaning in
> the platform, right?

So, let's be honest about why this bug isn't being fixed then.  Your
attitude to this problem is ignore it and to do nothing, rather than
trying to fix it via a perfectly good transition path provided for
you.

Okay, now we can see clearly why the bug is still there.  Thanks.

Given such an attitude, remind me why I should care whether iMX breaks
while we do the consolidation and cleanup work to core code, such as
the recent restart changes.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > today - the clk framework is totally irrelevant as far as this goes.
> > I think doing the clk_prepare seperation and converting to the clk
> > framework in one step will be easier.
> 
> From a point of view of being able to separate the changes so there isn't
> a flag day, you're wrong.  clk_prepare() is already present in the kernel
> as dummy functions, and all you need to do at this point is arrange for
> the drivers to make the appropriate calls.  There's no need to write one
> line of code behind clk_prepare() at the current time.
Yeah, but adding clk_prepare to the serial driver doesn't help me to get
rid of the BUG reported in this thread without giving it some meaning in
the platform, right?
 
> If you then want to provide a clk_prepare() implementation, then you need
> to select CONFIG_HAVE_CLK_PREPARE to prevent the dummy function being
> used.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > today - the clk framework is totally irrelevant as far as this goes.
> I think doing the clk_prepare seperation and converting to the clk
> framework in one step will be easier.

>From a point of view of being able to separate the changes so there isn't
a flag day, you're wrong.  clk_prepare() is already present in the kernel
as dummy functions, and all you need to do at this point is arrange for
the drivers to make the appropriate calls.  There's no need to write one
line of code behind clk_prepare() at the current time.

If you then want to provide a clk_prepare() implementation, then you need
to select CONFIG_HAVE_CLK_PREPARE to prevent the dummy function being
used.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > > Looks like the same error I faced before:
> > > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> > which resulted in some concerns about locking correctness. On i.MX28 we
> > usually use
> > 
> > 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> > 
> > (though this patch wasn't accepted either. The right fix is to convert
> > mxs to the upcoming clk framework, which didn't land into mainline yet.)
> 
> Irrespective of the clk framework.  If you convert to the clk_prepare()
> methodology, then you fix this bug.  You can do this as a two-step thing.
Yeah, OK, I should have said:

	The right fix is to make clk_enable atomic on mxs which back
	then was agreed to be done when converting to the new clk
	framework.

> [..]
>
> So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> today - the clk framework is totally irrelevant as far as this goes.
I think doing the clk_prepare seperation and converting to the clk
framework in one step will be easier.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Shawn Guo]

Hi Peter,

You can go ahead to submit your LRADC/Touch patches, and I will find
some time to get this fixed following Russell's suggestion.

Regards,
Shawn

On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > > Looks like the same error I faced before:
> > > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> > which resulted in some concerns about locking correctness. On i.MX28 we
> > usually use
> > 
> > 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> > 
> > (though this patch wasn't accepted either. The right fix is to convert
> > mxs to the upcoming clk framework, which didn't land into mainline yet.)
> 
> Irrespective of the clk framework.  If you convert to the clk_prepare()
> methodology, then you fix this bug.  You can do this as a two-step thing.
> First, convert _all_ your drivers to issue the correct clk_prepare() and
> clk_unprepare() calls at the appropriate time.  Once that's all done,
> convert your clk API implementation to doing the sleeping parts of your
> existing clk_enable() in clk_prepare() and leave the non-sleeping parts
> in clk_enable().  (Ditto for clk_disable() vs clk_unprepare().)
> 
> You'll need to do most of the driver work _before_ the clk framework
> lands, because it becomes mandatory for your drivers to call clk_prepare()
> with that.
> 
> Plus, on the implementation side, you'll already have done the work to
> separate the two for the clk framework, which in theory should mean that
> its easier to convert.
> 
> So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> today - the clk framework is totally irrelevant as far as this goes.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > Looks like the same error I faced before:
> > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> which resulted in some concerns about locking correctness. On i.MX28 we
> usually use
> 
> 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> 
> (though this patch wasn't accepted either. The right fix is to convert
> mxs to the upcoming clk framework, which didn't land into mainline yet.)

Irrespective of the clk framework.  If you convert to the clk_prepare()
methodology, then you fix this bug.  You can do this as a two-step thing.
First, convert _all_ your drivers to issue the correct clk_prepare() and
clk_unprepare() calls at the appropriate time.  Once that's all done,
convert your clk API implementation to doing the sleeping parts of your
existing clk_enable() in clk_prepare() and leave the non-sleeping parts
in clk_enable().  (Ditto for clk_disable() vs clk_unprepare().)

You'll need to do most of the driver work _before_ the clk framework
lands, because it becomes mandatory for your drivers to call clk_prepare()
with that.

Plus, on the implementation side, you'll already have done the work to
separate the two for the clk framework, which in theory should mean that
its easier to convert.

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
today - the clk framework is totally irrelevant as far as this goes.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

Hello,

On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> On Wed, Nov 23, 2011 at 9:36 AM, Peter Rusko <rusko.peter@prolan.hu> wrote:
> > While trying to use the LRADC and touchscreen functionality on imx28,
> > I've run into this problem:
> >
> > udevd[523]: starting version 171
> > BUG: sleeping function called from invalid context at kernel/mutex.c:271
> > in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
> > no locks held by udevd/523.
> > irq event stamp: 956
> > hardirqs last ?enabled at (956): [<c032e56c>]
> > _raw_write_unlock_irqrestore+0x3c/0x68
> > hardirqs last disabled at (955): [<c032e6ec>]
> > _raw_write_lock_irqsave+0x1c/0x58
> > softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
> > softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
> > [<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
> > (mutex_lock_nested+0x24/0x31c)
> > [<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
> > (clk_enable+0x20/0x48)
> > [<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
> > (pl011_console_write+0x20/0x78)
> > [<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
> > (__call_console_drivers+0x84/0x9c)
> > [<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
> > (console_unlock+0xfc/0x1ec)
> > [<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
> > (vprintk+0x3b0/0x440)
> > [<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
> > [<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
> > [<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
> > (do_sync_write+0x98/0xd4)
> > [<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
> > (vfs_write+0xc8/0x138)
> > [<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
> > [<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
> > (ret_fast_syscall+0x0/0x38)
> >
> > It seems that the printk calls cause the problem (it's not just with udev,
> > seems to have the problem with all printk calls). The touchscreen
> > works perfectly and I'd like to submit a patch which supports it, but I
> > keep getting the same messages. What can cause the problem, why is it an
> > atomic context within the udevd?
> 
> Looks like the same error I faced before:
> http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
which resulted in some concerns about locking correctness. On i.MX28 we
usually use

	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746

(though this patch wasn't accepted either. The right fix is to convert
mxs to the upcoming clk framework, which didn't land into mainline yet.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Fabio Estevam]

On Wed, Nov 23, 2011 at 10:44 AM, Fabio Estevam <festevam@gmail.com> wrote:

> Looks like the same error I faced before:
> http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Also, can you please try Sascha's imx-features branch?
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-features

It contains a patch series from Richard Zhao that introduces
clk_prepare that may possibly help with this issue.

BUG: sleeping function called from invalid context

[Fabio Estevam]

Peter,

On Wed, Nov 23, 2011 at 9:36 AM, Peter Rusko <rusko.peter@prolan.hu> wrote:
> Hi all,
>
> While trying to use the LRADC and touchscreen functionality on imx28,
> I've run into this problem:
>
> udevd[523]: starting version 171
> BUG: sleeping function called from invalid context at kernel/mutex.c:271
> in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
> no locks held by udevd/523.
> irq event stamp: 956
> hardirqs last ?enabled at (956): [<c032e56c>]
> _raw_write_unlock_irqrestore+0x3c/0x68
> hardirqs last disabled at (955): [<c032e6ec>]
> _raw_write_lock_irqsave+0x1c/0x58
> softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
> softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
> [<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
> (mutex_lock_nested+0x24/0x31c)
> [<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
> (clk_enable+0x20/0x48)
> [<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
> (pl011_console_write+0x20/0x78)
> [<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
> (__call_console_drivers+0x84/0x9c)
> [<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
> (console_unlock+0xfc/0x1ec)
> [<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
> (vprintk+0x3b0/0x440)
> [<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
> [<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
> [<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
> (do_sync_write+0x98/0xd4)
> [<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
> (vfs_write+0xc8/0x138)
> [<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
> [<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
> (ret_fast_syscall+0x0/0x38)
>
> It seems that the printk calls cause the problem (it's not just with udev,
> seems to have the problem with all printk calls). The touchscreen
> works perfectly and I'd like to submit a patch which supports it, but I
> keep getting the same messages. What can cause the problem, why is it an
> atomic context within the udevd?

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Regards,

Fabio Estevam

BUG: sleeping function called from invalid context

[Peter Rusko]

Hi all,

While trying to use the LRADC and touchscreen functionality on imx28,
I've run into this problem:

udevd[523]: starting version 171
BUG: sleeping function called from invalid context at kernel/mutex.c:271
in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
no locks held by udevd/523.
irq event stamp: 956
hardirqs last  enabled at (956): [<c032e56c>] 
_raw_write_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (955): [<c032e6ec>] 
_raw_write_lock_irqsave+0x1c/0x58
softirqs last  enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
[<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>] 
(mutex_lock_nested+0x24/0x31c)
[<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>] 
(clk_enable+0x20/0x48)
[<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>] 
(pl011_console_write+0x20/0x78)
[<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>] 
(__call_console_drivers+0x84/0x9c)
[<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>] 
(console_unlock+0xfc/0x1ec)
[<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>] 
(vprintk+0x3b0/0x440)
[<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
[<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
[<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>] 
(do_sync_write+0x98/0xd4)
[<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>] 
(vfs_write+0xc8/0x138)
[<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
[<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>] 
(ret_fast_syscall+0x0/0x38)

It seems that the printk calls cause the problem (it's not just with 
udev, seems to have the problem with all printk calls). The touchscreen
works perfectly and I'd like to submit a patch which supports it, but I
keep getting the same messages. What can cause the problem, why is it an
atomic context within the udevd?

Regards,
-- 
Rusk? P?ter
Fejleszt?m?rn?k

Prolan Zrt. / Prolan Co.
Hungary 2011 Budakal?sz, Szentendrei ?t 1-3.
Tel./Phone: +36 20 954 3118
Fax: +36 26 540 420
E-mail: rusko.peter at prolan.hu
Web: www.prolan.hu
Timezone:CET

Re: BUG: sleeping function called from invalid context

[Konrad Rzeszutek Wilk]

On Tue, Oct 11, 2011 at 07:13:38PM +0200, Dario Faggioli wrote:
> Hello everyone,
> 
> Since I really plan to spend some time here, let me introduce myself
> first. My name is Dario Faggioli and I just joined the Citrix Platform
> Team in Cambridge (although I'll be working from Italy). I've some
> experience in Linux kernel (mainly scheduling) and not that much
> experience in Xen or virtualization in general, but I really want to
> learn and be able to contribute ASAP!
> 
> In fact, while "doing my homework", I stumbled against the following
> BUG(). I'm able to reproduce it with xen-unstable and by just by
> enabling spinlock and mutex debug checks in linus' Linux
> (65112dccf8a113737684366349d7f9ec373ddc47) _iff_ using 'tap:qcow2' disk
> image, while no such thing happens with 'phy:'.

Aha.. I saw that at some point but never narrowed it down to the
right combination. Thank you for tracking this down.

I am CC Daniel who might have some patches for this or ideas.
> 
> [  996.282544] BUG: sleeping function called from invalid context at /local/scratch/dariof/linux/kernel/mutex.c:271
> [  996.282570] in_atomic(): 1, irqs_disabled(): 0, pid: 3256, name: qemu-dm
> [  996.282581] 1 lock held by qemu-dm/3256:
> [  996.282589]  #0:  (&(&priv->lock)->rlock){......}, at: [<ffffffff813223da>] gntdev_ioctl+0x2bd/0x4d5
> [  996.282628] Pid: 3256, comm: qemu-dm Tainted: G        W   3.1.0-rc8+ #5
> [  996.282638] Call Trace:
> [  996.282687]  [<ffffffff81054594>] __might_sleep+0x131/0x135
> [  996.282704]  [<ffffffff816bd64f>] mutex_lock_nested+0x25/0x45
> [  996.282721]  [<ffffffff8131c7c8>] free_xenballooned_pages+0x20/0xb1
> [  996.282735]  [<ffffffff8132194d>] gntdev_put_map+0xa8/0xdb
> [  996.282749]  [<ffffffff816be546>] ? _raw_spin_lock+0x71/0x7a
> [  996.282763]  [<ffffffff813223da>] ? gntdev_ioctl+0x2bd/0x4d5
> [  996.282776]  [<ffffffff8132243c>] gntdev_ioctl+0x31f/0x4d5
> [  996.282790]  [<ffffffff81007d62>] ? check_events+0x12/0x20
> [  996.282804]  [<ffffffff811433bc>] do_vfs_ioctl+0x488/0x4d7
> [  996.282818]  [<ffffffff81007d4f>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [  996.282832]  [<ffffffff8109168b>] ? lock_release+0x21c/0x229
> [  996.282847]  [<ffffffff81135cdd>] ? rcu_read_unlock+0x21/0x32
> [  996.282860]  [<ffffffff81143452>] sys_ioctl+0x47/0x6a
> [  996.282873]  [<ffffffff816bfd82>] system_call_fastpath+0x16/0x1b
> 
> This seems to be due to free_xenballooned_pages(), called by
> gntdev_put_map(), taking balloon_mutex, with the latter that can be
> called within a spin_lock() (e.g., in gntdev_release()).
> 
> I'm not enough confident with the code do attempt fixing it, but I
> thought it was worth to at least point it out!

BUG: sleeping function called from invalid context

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2756 bytes --]

Hello everyone,

Since I really plan to spend some time here, let me introduce myself
first. My name is Dario Faggioli and I just joined the Citrix Platform
Team in Cambridge (although I'll be working from Italy). I've some
experience in Linux kernel (mainly scheduling) and not that much
experience in Xen or virtualization in general, but I really want to
learn and be able to contribute ASAP!

In fact, while "doing my homework", I stumbled against the following
BUG(). I'm able to reproduce it with xen-unstable and by just by
enabling spinlock and mutex debug checks in linus' Linux
(65112dccf8a113737684366349d7f9ec373ddc47) _iff_ using 'tap:qcow2' disk
image, while no such thing happens with 'phy:'.

[  996.282544] BUG: sleeping function called from invalid context at /local/scratch/dariof/linux/kernel/mutex.c:271
[  996.282570] in_atomic(): 1, irqs_disabled(): 0, pid: 3256, name: qemu-dm
[  996.282581] 1 lock held by qemu-dm/3256:
[  996.282589]  #0:  (&(&priv->lock)->rlock){......}, at: [<ffffffff813223da>] gntdev_ioctl+0x2bd/0x4d5
[  996.282628] Pid: 3256, comm: qemu-dm Tainted: G        W   3.1.0-rc8+ #5
[  996.282638] Call Trace:
[  996.282687]  [<ffffffff81054594>] __might_sleep+0x131/0x135
[  996.282704]  [<ffffffff816bd64f>] mutex_lock_nested+0x25/0x45
[  996.282721]  [<ffffffff8131c7c8>] free_xenballooned_pages+0x20/0xb1
[  996.282735]  [<ffffffff8132194d>] gntdev_put_map+0xa8/0xdb
[  996.282749]  [<ffffffff816be546>] ? _raw_spin_lock+0x71/0x7a
[  996.282763]  [<ffffffff813223da>] ? gntdev_ioctl+0x2bd/0x4d5
[  996.282776]  [<ffffffff8132243c>] gntdev_ioctl+0x31f/0x4d5
[  996.282790]  [<ffffffff81007d62>] ? check_events+0x12/0x20
[  996.282804]  [<ffffffff811433bc>] do_vfs_ioctl+0x488/0x4d7
[  996.282818]  [<ffffffff81007d4f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  996.282832]  [<ffffffff8109168b>] ? lock_release+0x21c/0x229
[  996.282847]  [<ffffffff81135cdd>] ? rcu_read_unlock+0x21/0x32
[  996.282860]  [<ffffffff81143452>] sys_ioctl+0x47/0x6a
[  996.282873]  [<ffffffff816bfd82>] system_call_fastpath+0x16/0x1b

This seems to be due to free_xenballooned_pages(), called by
gntdev_put_map(), taking balloon_mutex, with the latter that can be
called within a spin_lock() (e.g., in gntdev_release()).

I'm not enough confident with the code do attempt fixing it, but I
thought it was worth to at least point it out!

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: BUG: sleeping function called from invalid context

[Alan Cox]

> On analysis, I found that this is due to the change introduced in 
> tty_ioctl.c where the termios mutex is taken to protect against
> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
> tested before merging this patch.
> 
> Please suggest what should be done with the IrCOMM protocol stack
> code to resolve this problem?

It looks like the comments are wrong 

        /*
         * Just give it over to the line discipline. There is no need to
         * involve the flip buffers, since we are not running in an
        interrupt
         * handler
         */


appears to be completely untrue

I suspect it just needs to use the tty_flip_buffer functions properly
instead of trying to do clever shortcuts


	tty_insert_flip_string(self->tty, skb->data, skb->len);
	tty_flip_buffer_push(self->tty);

Re: BUG: sleeping function called from invalid context

[Alan Cox]

> On analysis, I found that this is due to the change introduced in 
> tty_ioctl.c where the termios mutex is taken to protect against
> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
> tested before merging this patch.
> 
> Please suggest what should be done with the IrCOMM protocol stack
> code to resolve this problem?

It looks like the comments are wrong 

        /*
         * Just give it over to the line discipline. There is no need to
         * involve the flip buffers, since we are not running in an
        interrupt
         * handler
         */


appears to be completely untrue

I suspect it just needs to use the tty_flip_buffer functions properly
instead of trying to do clever shortcuts


	tty_insert_flip_string(self->tty, skb->data, skb->len);
	tty_flip_buffer_push(self->tty);

BUG: sleeping function called from invalid context

[Alan Cox]

> On analysis, I found that this is due to the change introduced in 
> tty_ioctl.c where the termios mutex is taken to protect against
> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
> tested before merging this patch.
> 
> Please suggest what should be done with the IrCOMM protocol stack
> code to resolve this problem?

It looks like the comments are wrong 

        /*
         * Just give it over to the line discipline. There is no need to
         * involve the flip buffers, since we are not running in an
        interrupt
         * handler
         */


appears to be completely untrue

I suspect it just needs to use the tty_flip_buffer functions properly
instead of trying to do clever shortcuts


	tty_insert_flip_string(self->tty, skb->data, skb->len);
	tty_flip_buffer_push(self->tty);

BUG: sleeping function called from invalid context

[Amit Virdi]

Hi

I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast 
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and 
using PPP over it.

While testing, I'm getting the following backtrace repeatedly:

=====================================
BUG: sleeping function called from invalid context at 
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>] 
(dump_stack+0x18/0x1c)
  r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>] 
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>] 
(mutex_lock+0x24/0x44)
  r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>] 
(tty_unthrottle+0x1c/0x64)
  r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>] 
(ppp_asynctty_receive+0x484/0x4a4)
  r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>] 
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>] 
(ircomm_data_indication+0x7c/0xb4)
  r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>] 
(ircomm_process_data+0x110/0x160)
  r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>] 
(ircomm_state_conn+0x60/0xec)
  r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>] 
(ircomm_do_event+0x6c/0x88)
  r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>] 
(ircomm_ttp_data_indication+0xbc/0xf4)
  r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>] 
(irttp_do_data_indication+0x44/0x8c)
  r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>] 
(irttp_run_rx_queue+0xac/0x318)
  r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>] 
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>] 
(irlmp_data_indication+0x5c/0x60)
  r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>] 
(irlmp_link_data_indication+0x2fc/0x35c)
  r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>] 
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>] 
(irlap_state_nrm_s+0x208/0x7e0)
  r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>] 
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>] 
(irlap_driver_rcv+0x178/0xc34)
  r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>] 
(__netif_receive_skb+0x348/0x39c)
  r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>] 
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>] 
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>] 
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c 
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694 
c002e6a0
df80: 60000013 ffffffff
  r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
  r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>] 
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================

On analysis, I found that this is due to the change introduced in 
tty_ioctl.c where the termios mutex is taken to protect against parallel 
throttle/unthrottle. Probably IrCOMM stack code wasn't tested before 
merging this patch.

Please suggest what should be done with the IrCOMM protocol stack code 
to resolve this problem?

Thanks
~Amit Virdi

BUG: sleeping function called from invalid context

[Amit Virdi]

Hi

I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast 
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and 
using PPP over it.

While testing, I'm getting the following backtrace repeatedly:

=====================================
BUG: sleeping function called from invalid context at 
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>] 
(dump_stack+0x18/0x1c)
  r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>] 
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>] 
(mutex_lock+0x24/0x44)
  r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>] 
(tty_unthrottle+0x1c/0x64)
  r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>] 
(ppp_asynctty_receive+0x484/0x4a4)
  r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>] 
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>] 
(ircomm_data_indication+0x7c/0xb4)
  r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>] 
(ircomm_process_data+0x110/0x160)
  r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>] 
(ircomm_state_conn+0x60/0xec)
  r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>] 
(ircomm_do_event+0x6c/0x88)
  r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>] 
(ircomm_ttp_data_indication+0xbc/0xf4)
  r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>] 
(irttp_do_data_indication+0x44/0x8c)
  r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>] 
(irttp_run_rx_queue+0xac/0x318)
  r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>] 
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>] 
(irlmp_data_indication+0x5c/0x60)
  r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>] 
(irlmp_link_data_indication+0x2fc/0x35c)
  r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>] 
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>] 
(irlap_state_nrm_s+0x208/0x7e0)
  r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>] 
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>] 
(irlap_driver_rcv+0x178/0xc34)
  r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>] 
(__netif_receive_skb+0x348/0x39c)
  r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>] 
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>] 
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>] 
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c 
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694 
c002e6a0
df80: 60000013 ffffffff
  r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
  r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>] 
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================

On analysis, I found that this is due to the change introduced in 
tty_ioctl.c where the termios mutex is taken to protect against parallel 
throttle/unthrottle. Probably IrCOMM stack code wasn't tested before 
merging this patch.

Please suggest what should be done with the IrCOMM protocol stack code 
to resolve this problem?

Thanks
~Amit Virdi

BUG: sleeping function called from invalid context

[Amit Virdi]

Hi

I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast 
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and 
using PPP over it.

While testing, I'm getting the following backtrace repeatedly:

=====================================
BUG: sleeping function called from invalid context at 
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>] 
(dump_stack+0x18/0x1c)
  r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>] 
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>] 
(mutex_lock+0x24/0x44)
  r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>] 
(tty_unthrottle+0x1c/0x64)
  r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>] 
(ppp_asynctty_receive+0x484/0x4a4)
  r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>] 
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>] 
(ircomm_data_indication+0x7c/0xb4)
  r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>] 
(ircomm_process_data+0x110/0x160)
  r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>] 
(ircomm_state_conn+0x60/0xec)
  r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>] 
(ircomm_do_event+0x6c/0x88)
  r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>] 
(ircomm_ttp_data_indication+0xbc/0xf4)
  r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>] 
(irttp_do_data_indication+0x44/0x8c)
  r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>] 
(irttp_run_rx_queue+0xac/0x318)
  r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>] 
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>] 
(irlmp_data_indication+0x5c/0x60)
  r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>] 
(irlmp_link_data_indication+0x2fc/0x35c)
  r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>] 
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>] 
(irlap_state_nrm_s+0x208/0x7e0)
  r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>] 
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>] 
(irlap_driver_rcv+0x178/0xc34)
  r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>] 
(__netif_receive_skb+0x348/0x39c)
  r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>] 
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>] 
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>] 
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c 
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694 
c002e6a0
df80: 60000013 ffffffff
  r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
  r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>] 
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================

On analysis, I found that this is due to the change introduced in 
tty_ioctl.c where the termios mutex is taken to protect against parallel 
throttle/unthrottle. Probably IrCOMM stack code wasn't tested before 
merging this patch.

Please suggest what should be done with the IrCOMM protocol stack code 
to resolve this problem?

Thanks
~Amit Virdi

BUG: sleeping function called from invalid context

[Ilpo Järvinen]

I booted up net-next-2.6 based kernel under kvm and keep getting this one:

BUG: sleeping function called from invalid context at mm/slub.c:1719
in_atomic(): 1, irqs_disabled(): 0, pid: 2847, name: dhclient3
1 lock held by dhclient3/2847:
 #0:  (rcu_read_lock){.+.+.+}, at: [<ffffffff813bf681>] packet_sendmsg_spkt+0x56/0x28b
Pid: 2847, comm: dhclient3 Not tainted 2.6.32-rc7-03467-g5e75659 #51
Call Trace:
 [<ffffffff8106a926>] ? __debug_show_held_locks+0x22/0x24
 [<ffffffff8103b405>] __might_sleep+0x126/0x12b
 [<ffffffff810d4b25>] kmem_cache_alloc+0x46/0x14e
 [<ffffffff812f9e7a>] __alloc_skb+0x3c/0x15b
 [<ffffffff812f4ffe>] sock_wmalloc+0x31/0x78
 [<ffffffff813bf732>] packet_sendmsg_spkt+0x107/0x28b
 [<ffffffff813bf681>] ? packet_sendmsg_spkt+0x56/0x28b
 [<ffffffff812f1c37>] sock_sendmsg+0xdf/0xf8
 [<ffffffff810d2389>] ? add_partial+0x1a/0x69
 [<ffffffff8105cd8e>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff813e86d1>] ? _spin_unlock+0x30/0x4b
 [<ffffffff810d2389>] ? add_partial+0x1a/0x69
 [<ffffffff810d23d0>] ? add_partial+0x61/0x69
 [<ffffffff810d679b>] ? kmem_cache_free+0xcb/0x138
 [<ffffffff8106b539>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff812f34f8>] ? move_addr_to_kernel+0x40/0x49
 [<ffffffff812f35e0>] sys_sendto+0xdf/0x107
 [<ffffffff810f031c>] ? mntput_no_expire+0x24/0xf0
 [<ffffffff8100bbc2>] system_call_fastpath+0x16/0x1b


-- 
 i.

Re: BUG: sleeping function called from invalid context

[Holger Schurig]

> What I don't know is why something is calling
> get_wireless_stats() when setting the essid. This happens way
> before a call into lbs_set_essid() (the WEXT handler), as can
> be seen from the log below.

Okay, that question has now an answer: an strace of iwconfig 
(wireless-tools 29~pre22-1~bpo40+1) does 
open /proc/net/wireless, which in turn calls 
lbs_get_wireless_stats().

This happens before the SIOCSIWESSID ioctl().

BUG: sleeping function called from invalid context

[Holger Schurig]

Here is something I haven't yet debugged and where I am a little 
bit clueless.

Situation: libertas has associated to an AP successfully and I 
run "iwconfig eth1 essid BLAHLABER". Everything is o.k. when I 
run the same command while not associated.

What I don't know is why something is calling 
get_wireless_stats() when setting the essid. This happens way 
before a call into lbs_set_essid() (the WEXT handler), as can be 
seen from the log below.


libertas enter: lbs_ret_80211_associate()
libertas assoc: associated to 00:13:19:80:da:30
##HS iwconfig eth1 essid BLAHLABER
libertas enter: lbs_get_wireless_stats()
libertas wext: signal level 0xd2
libertas wext: noise 0xa8
BUG: sleeping function called from invalid context at 
drivers/net/wireless/libertas/cmd.c:2013
in_atomic():1, irqs_disabled():0
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0114e77>] __might_sleep+0xb3/0xb8
 [<f8837d9f>] __lbs_cmd+0x8b/0x175 [libertas]
 [<c0119477>] ? printk+0x15/0x17
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
BUG: scheduling while atomic: iwconfig/16494/0x00000002
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0115d6b>] __schedule_bug+0x58/0x5f
 [<c032a863>] schedule+0x5b/0x2d1
 [<c0127d82>] ? prepare_to_wait+0x4d/0x53
 [<f8837df5>] __lbs_cmd+0xe1/0x175 [libertas]
 [<c0127c25>] ? autoremove_wake_function+0x0/0x33
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
BUG: scheduling while atomic: iwconfig/16494/0x00000002
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0115d6b>] __schedule_bug+0x58/0x5f
 [<c032a863>] schedule+0x5b/0x2d1
 [<c0127d82>] ? prepare_to_wait+0x4d/0x53
 [<f8837df5>] __lbs_cmd+0xe1/0x175 [libertas]
 [<c0127c25>] ? autoremove_wake_function+0x0/0x33
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
libertas enter: lbs_set_essid()
libertas wext: requested SSID 'MNHS'

This happens with libertas from wireless-testing 
v2.6.25-6933-g0bacadf.