Hi Arun, On Wed, Apr 18, 2012 at 1:58 AM, Arun KS <getarunks@xxxxxxxxx> wrote: > > > On Wed, Apr 18, 2012 at 12:14 PM, Arun KS <getarunks@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
