From: srivatsa.bhat@linux.vnet.ibm.com (Srivatsa S. Bhat)
To: kernelnewbies@lists.kernelnewbies.org
Subject: BUG: scheduling while atomic
Date: Wed, 18 Apr 2012 13:57:36 +0530 [thread overview]
Message-ID: <4F8E7AF8.3050202@linux.vnet.ibm.com> (raw)
In-Reply-To: <CABOM9ZoZTK6HqJW4yT2kmXNnDkByMGn+S7KqPF7x+cizJ8pguQ@mail.gmail.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
next prev parent reply other threads:[~2012-04-18 8:27 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABOM9ZqSazS-NkD980f6sUyy=hk1aLVY+Vjwcxs3mGybvbkgaQ@mail.gmail.com>
2012-04-18 6:44 ` BUG: scheduling while atomic Arun KS
2012-04-18 7:31 ` Dave Hylands
2012-04-18 8:08 ` Arun KS
2012-04-18 8:14 ` Dave Hylands
2012-04-18 8:27 ` Srivatsa S. Bhat [this message]
2012-04-18 8:40 ` Arun KS
2012-04-18 8:58 ` Arun KS
2012-04-18 15:40 ` Dave Hylands
2018-08-05 14:09 James Courtier-Dutton
2018-08-06 0:48 ` Qu Wenruo
[not found] ` <CAAMvbhGJdGobexGS0QEGDexNeZpZkJY3o_s9N4izZeEJ7-HWtA@mail.gmail.com>
2018-08-06 6:26 ` Qu Wenruo
2018-08-10 22:14 ` James Courtier-Dutton
2018-08-10 23:26 ` Qu Wenruo
-- strict thread matches above, loose matches on Subject: below --
2014-09-17 9:12 Mushtaq Khan
2015-02-17 10:18 ` Sebastian Andrzej Siewior
2012-02-13 8:08 Florian Tobias Schandinat
2012-02-13 8:08 ` Florian Tobias Schandinat
2011-12-09 10:00 Amon Ott
2011-12-14 23:59 ` Samuel Just
2011-12-05 9:12 Bug:scheduling " sandeep kumar
2011-12-05 19:03 ` Jonathan Neuschäfer
2011-12-05 19:16 ` Jonathan Neuschäfer
2011-05-10 5:51 BUG: scheduling " sandeep kumar
2011-05-10 6:08 ` Dave Hylands
2010-08-27 7:59 Sergey Senozhatsky
2010-08-27 19:02 ` Rafael J. Wysocki
2010-08-28 6:42 ` Pavel Machek
2010-08-28 6:42 ` Pavel Machek
2010-08-30 7:29 ` Sergey Senozhatsky
2010-08-30 7:29 ` Sergey Senozhatsky
2010-08-30 10:04 ` Sergey Senozhatsky
2010-08-30 10:04 ` Sergey Senozhatsky
2010-08-27 19:02 ` Rafael J. Wysocki
2010-08-27 7:59 Sergey Senozhatsky
2009-06-27 11:10 Michael Guntsche
2009-06-27 13:06 ` Alan Cox
2009-06-27 16:07 ` Michael Guntsche
2009-07-06 7:43 ` Herbert Xu
2009-07-06 8:31 ` Herbert Xu
2009-07-06 15:28 ` Michael Guntsche
2009-07-06 15:32 ` Alan Cox
2009-07-06 17:17 ` Alan Cox
2009-07-06 18:07 ` Michael Guntsche
2009-07-06 18:18 ` Alan Cox
2009-07-06 18:37 ` Michael Guntsche
2009-07-06 10:00 ` Alan Cox
2009-06-19 18:15 Sergey Senozhatsky
2009-06-20 17:43 ` Rabin Vincent
2009-06-20 18:54 ` Sergey Senozhatsky
2009-06-22 9:04 ` Alan Cox
2009-06-22 9:57 ` Alan Cox
2009-06-22 11:33 ` Sergey Senozhatsky
2009-06-22 12:36 ` Alan Cox
2009-06-22 13:59 ` Sergey Senozhatsky
2009-07-06 7:55 ` Herbert Xu
2009-04-07 6:29 Bug:scheduling " Vijay Nikam
2009-04-07 6:42 ` Kumar Gala
2008-03-17 15:00 BUG: scheduling " Holger Schurig
2008-03-17 15:13 ` Johannes Berg
2008-03-17 15:54 ` Holger Schurig
2008-02-19 22:22 John Linn
2007-07-30 17:07 Girish kathalagiri
2006-12-08 15:47 Christian
2006-06-02 9:39 fonseka
2006-06-02 12:37 ` Roger Luethi
2006-06-02 14:07 ` fonseka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F8E7AF8.3050202@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.