BUG: scheduling while atomic
Hello Guys, System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address. Just wondering how can this BUG happen when a process is running in user space. Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space. 3) and now it can happen in user space? Any thoughts? shell@android: # ls device[ 40.603515] BUG: scheduling while atomic: Binder Thread #/1355/0x00010003 [ 40.610290] Modules linked in: [ 40.613342] [ 40.614837] Pid: 1355, comm: Binder Thread # [ 40.619506] CPU: 0 Tainted: G W (3.0.15+ #174) [ 40.625061] PC is at 0x400b4614 [ 40.628173] LR is at 0x408d83c9 [ 40.631317] pc : [<400b4614>] lr : [<408d83c9>] psr: 40000010 [ 40.631317] sp : 50551918 ip : 4092d1c0 fp : 505519a4 [ 40.642730] r10: 50551974 r9 : 5016de28 r8 : 1f600009 [ 40.647949] r7 : 00000000 r6 : 00000000 r5 : 5055194c r4 : 00f09f90 [ 40.654418] r3 : 40931c58 r2 : 00000000 r1 : 00f09f90 r0 : 00000006 [ 40.660919] Flags: nZcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user [ 40.668121] Control: 10c53c7d Table: 91184059 DAC: 00000015 shell@android: # shell@android: # shell@android: #
Hi Arun, On Tue, Apr 17, 2012 at 11:44 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Guys,
System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address.
Just wondering how can this BUG happen when a process is running in user space.
Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space.
Don't do that.
3) and now it can happen in user space?
Because something in userspace made a blocking call which would cause a context switch to occur and your driver erroneously left interrupts disabled. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Hi Dave, Thanks for your reply. On Wed, Apr 18, 2012 at 1:01 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Arun,
On Tue, Apr 17, 2012 at 11:44 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Guys,
System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address.
Just wondering how can this BUG happen when a process is running in user space.
Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space.
Don't do that
I don't do that. This scenario mentioned is a just a wild guess.
3) and now it can happen in user space?
Because something in userspace made a blocking call which would cause a context switch to occur and your driver erroneously left interrupts disabled.
In that case, my system should have been unstable afterwards if interrupts are left disabled. But that is not happening. If we return to user space with interrupts disabled, can we switch back again to kernel using a system cal(because interrupts are already disabled)? Arun
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
Hi Arun, On Wed, Apr 18, 2012 at 1:08 AM, Arun KS <getarunks@gmail.com> wrote:
Hi Dave,
Thanks for your reply.
On Wed, Apr 18, 2012 at 1:01 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Arun,
On Tue, Apr 17, 2012 at 11:44 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Guys,
System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address.
Just wondering how can this BUG happen when a process is running in user space.
Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space.
Don't do that
I don't do that. This scenario mentioned is a just a wild guess.
3) and now it can happen in user space?
Because something in userspace made a blocking call which would cause a context switch to occur and your driver erroneously left interrupts disabled.
In that case, my system should have been unstable afterwards if interrupts are left disabled. But that is not happening.
If we return to user space with interrupts disabled, can we switch back again to kernel using a system cal(because interrupts are already disabled)?
As long as you don't do anything which would need to block. A buggy driver could also interrupt user-code (hardware interrupt) and disable interrupts and not re-enable them. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
On 04/18/2012 01:38 PM, Arun KS wrote:
Hi Dave,
Thanks for your reply.
On Wed, Apr 18, 2012 at 1:01 PM, Dave Hylands <dhylands@gmail.com <mailto:dhylands@gmail.com>> wrote:
Hi Arun,
On Tue, Apr 17, 2012 at 11:44 PM, Arun KS <getarunks@gmail.com <mailto:getarunks@gmail.com>> wrote: > > Hello Guys, > > System is working normal after this BUG. > PC is at 0x400b4614, probably a mmaped address. > > Just wondering how can this BUG happen when a process is running in user > space. > > Can it be something like this > 1) enter to kernel from userspace through some system call. > 2) kernel disables the interrupt and return to user space.
Don't do that
I don't do that. This scenario mentioned is a just a wild guess.
> 3) and now it can happen in user space?
Because something in userspace made a blocking call which would cause a context switch to occur and your driver erroneously left interrupts disabled.
In that case, my system should have been unstable afterwards if interrupts are left disabled. But that is not happening.
If we return to user space with interrupts disabled, can we switch back again to kernel using a system cal(because interrupts are already disabled)?
Depends on how many CPUs you have - AFAICS the "interrupts disabled" discussion above applies to a single CPU.. so if you have other CPUs on your system, you could probably use the system for a little more time. There is a simple way to check if interrupts are indeed disabled as hypothesised: turn on the hard-lockup detector (See Documentation/lockup-watchdogs.txt for details on what it is and what config options you have to enable). You can even turn on the soft-lockup detector and see what you get. Setting the option to panic on hard-lockup/ soft-lockup/hung tasks would be even better, to debug the issue. Regards, Srivatsa S. Bhat
On Wed, Apr 18, 2012 at 12:14 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Guys,
System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address.
Just wondering how can this BUG happen when a process is running in user space.
Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space. 3) and now it can happen in user space?
Any thoughts?
shell@android: # ls device[ 40.603515] BUG: scheduling while atomic: Binder Thread #/1355/0x00010003 [ 40.610290] Modules linked in: [ 40.613342] [ 40.614837] Pid: 1355, comm: Binder Thread # [ 40.619506] CPU: 0 Tainted: G W (3.0.15+ #174) [ 40.625061] PC is at 0x400b4614 [ 40.628173] LR is at 0x408d83c9 [ 40.631317] pc : [<400b4614>] lr : [<408d83c9>] psr: 40000010 [ 40.631317] sp : 50551918 ip : 4092d1c0 fp : 505519a4 [ 40.642730] r10: 50551974 r9 : 5016de28 r8 : 1f600009 [ 40.647949] r7 : 00000000 r6 : 00000000 r5 : 5055194c r4 : 00f09f90 [ 40.654418] r3 : 40931c58 r2 : 00000000 r1 : 00f09f90 r0 : 00000006 [ 40.660919] Flags: nZcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
But if you look at the flags here, it is showing that IRQs are on. [ 40.668121] Control: 10c53c7d Table: 91184059 DAC: 00000015
shell@android: # shell@android: # shell@android: #
Hi Arun, On Wed, Apr 18, 2012 at 1:58 AM, Arun KS <getarunks@gmail.com> wrote:
On Wed, Apr 18, 2012 at 12:14 PM, Arun KS <getarunks@gmail.com> wrote:
Hello Guys,
System is working normal after this BUG. PC is at 0x400b4614, probably a mmaped address.
Just wondering how can this BUG happen when a process is running in user space.
Can it be something like this 1) enter to kernel from userspace through some system call. 2) kernel disables the interrupt and return to user space. 3) and now it can happen in user space?
Any thoughts?
shell@android: # ls device[ 40.603515] BUG: scheduling while atomic: Binder Thread #/1355/0x00010003 [ 40.610290] Modules linked in: [ 40.613342] [ 40.614837] Pid: 1355, comm: Binder Thread # [ 40.619506] CPU: 0 Tainted: G W (3.0.15+ #174) [ 40.625061] PC is at 0x400b4614 [ 40.628173] LR is at 0x408d83c9 [ 40.631317] pc : [<400b4614>] lr : [<408d83c9>] psr: 40000010 [ 40.631317] sp : 50551918 ip : 4092d1c0 fp : 505519a4 [ 40.642730] r10: 50551974 r9 : 5016de28 r8 : 1f600009 [ 40.647949] r7 : 00000000 r6 : 00000000 r5 : 5055194c r4 : 00f09f90 [ 40.654418] r3 : 40931c58 r2 : 00000000 r1 : 00f09f90 r0 : 00000006 [ 40.660919] Flags: nZcv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
But if you look at the flags here, it is showing that IRQs are on.
[ 40.668121] Control: 10c53c7d Table: 91184059 DAC: 00000015
So, an atomic context, as far as the kernel is concerned, also includes disabling preemption, not just disabling interrupts. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
participants (3)
-
Arun KS -
Dave Hylands -
Srivatsa S. Bhat