BUG: scheduling while atomic

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