From mboxrd@z Thu Jan 1 00:00:00 1970 From: getarunks@gmail.com (Arun KS) Date: Wed, 18 Apr 2012 14:10:40 +0530 Subject: BUG: scheduling while atomic In-Reply-To: <4F8E7AF8.3050202@linux.vnet.ibm.com> References: <4F8E7AF8.3050202@linux.vnet.ibm.com> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org Hi Srivatsa, On Wed, Apr 18, 2012 at 1:57 PM, Srivatsa S. Bhat < srivatsa.bhat@linux.vnet.ibm.com> wrote: > 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 > > wrote: > > > > Hi Arun, > > > > On Tue, Apr 17, 2012 at 11:44 PM, Arun KS > > 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. > > > Hmm.. I have uniprocessor. > > 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. > Thanks for the pointers. I ll try this out. Arun > > Regards, > Srivatsa S. Bhat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120418/87ed6fc2/attachment.html