"scheduling while atomic" ?

"scheduling while atomic" ?

[Mateusz Berezecki]

Hi LKML,

What does the message saying "scheduling while atomic" mean?

The kernel prints a stack backtrace after this message appears so I
suppose this is
not a good behaviour. I am finishing an open source driver, and I need
to do all of this
locking stuff, etc. and this really makes me wonder what I am doing wrong.

here is some part of a backtrace...

scheduling while atomic: insmod/0x00000001/12692
 [<c03e7352>] schedule+0x632/0x640
 [<c0119bb1>] __wake_up_common+0x41/0x70
 [<c03e74df>] wait_for_completion+0x8f/0xf0
 [<c0119b50>] default_wake_function+0x0/0x20
 [<c0119b50>] default_wake_function+0x0/0x20
 [<c012e2dd>] queue_work+0x8d/0xa0
 [<c012e070>] __call_usermodehelper+0x0/0x70
 [<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0
 [<c012e070>] __call_usermodehelper+0x0/0x70
 [<c020c028>] sprintf+0x28/0x30
 [<c020955d>] kobject_hotplug+0x29d/0x310
 [<c019fc6e>] sysfs_create_link+0x3e/0x60
 [<c028b601>] class_device_add+0x161/0x1e0
 [<c036f38e>] netdev_register_sysfs+0x3e/0x100
 [<c03650db>] netdev_run_todo+0x1eb/0x220
 [<c0364dce>] register_netdev+0x5e/0x90

I enable a lock at the beginning of device attach routine
and I disable it at the end. Whats wrong with it?



regards
Mateusz

Re: "scheduling while atomic" ?

[Richard B. Johnson]

On Tue, 12 Jul 2005, Mateusz Berezecki wrote:

> Hi LKML,
>
> What does the message saying "scheduling while atomic" mean?
>
> The kernel prints a stack backtrace after this message appears so I
> suppose this is
> not a good behaviour. I am finishing an open source driver, and I need
> to do all of this
> locking stuff, etc. and this really makes me wonder what I am doing wrong.
>
> here is some part of a backtrace...
>
> scheduling while atomic: insmod/0x00000001/12692
> [<c03e7352>] schedule+0x632/0x640
> [<c0119bb1>] __wake_up_common+0x41/0x70
> [<c03e74df>] wait_for_completion+0x8f/0xf0
> [<c0119b50>] default_wake_function+0x0/0x20
> [<c0119b50>] default_wake_function+0x0/0x20
> [<c012e2dd>] queue_work+0x8d/0xa0
> [<c012e070>] __call_usermodehelper+0x0/0x70
> [<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0
> [<c012e070>] __call_usermodehelper+0x0/0x70
> [<c020c028>] sprintf+0x28/0x30
> [<c020955d>] kobject_hotplug+0x29d/0x310
> [<c019fc6e>] sysfs_create_link+0x3e/0x60
> [<c028b601>] class_device_add+0x161/0x1e0
> [<c036f38e>] netdev_register_sysfs+0x3e/0x100
> [<c03650db>] netdev_run_todo+0x1eb/0x220
> [<c0364dce>] register_netdev+0x5e/0x90
>
> I enable a lock at the beginning of device attach routine
> and I disable it at the end. Whats wrong with it?

You probably have the interrupts disabled (a spin-lock locked)
when some timer or other routine that will schedule() is called.

Also, make sure that you initialize all your spin-locks and
semaphores before you try to use them.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: "scheduling while atomic" ?

[Steven Rostedt]

On Tue, 2005-07-12 at 15:19 +0200, Mateusz Berezecki wrote:
> Hi LKML,
> 
> What does the message saying "scheduling while atomic" mean?

It means that you called schedule with preemption turned off, which
could be by grabbing a spin_lock.

> The kernel prints a stack backtrace after this message appears so I
> suppose this is
> not a good behaviour. I am finishing an open source driver, and I need
> to do all of this
> locking stuff, etc. and this really makes me wonder what I am doing wrong.
> 
> here is some part of a backtrace...
> 
> scheduling while atomic: insmod/0x00000001/12692
>  [<c03e7352>] schedule+0x632/0x640
>  [<c0119bb1>] __wake_up_common+0x41/0x70
>  [<c03e74df>] wait_for_completion+0x8f/0xf0
>  [<c0119b50>] default_wake_function+0x0/0x20
>  [<c0119b50>] default_wake_function+0x0/0x20
>  [<c012e2dd>] queue_work+0x8d/0xa0
>  [<c012e070>] __call_usermodehelper+0x0/0x70
>  [<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0
>  [<c012e070>] __call_usermodehelper+0x0/0x70
>  [<c020c028>] sprintf+0x28/0x30
>  [<c020955d>] kobject_hotplug+0x29d/0x310
>  [<c019fc6e>] sysfs_create_link+0x3e/0x60
>  [<c028b601>] class_device_add+0x161/0x1e0
>  [<c036f38e>] netdev_register_sysfs+0x3e/0x100
>  [<c03650db>] netdev_run_todo+0x1eb/0x220
>  [<c0364dce>] register_netdev+0x5e/0x90
> 
> I enable a lock at the beginning of device attach routine
> and I disable it at the end. Whats wrong with it?

When you say enable a lock, do you mean that you grabbed a lock?  Now if
you grabbed a spinlock, it is really bad to then call schedule, since a
another process that will grab that same spinlock will deadlock the CPU
(on an SMP system). Since you are using locks (I'm also assuming that
you are using spinlocks) I assume that you will be running this on a
CONFIG_PREEMPT or SMP system.

So the fix will be to release the lock before calling something that
will schedule, and regrab it afterwards.

-- Steve

Re: "scheduling while atomic" ?

[Mateusz Berezecki]

>When you say enable a lock, do you mean that you grabbed a lock?  Now if
>you grabbed a spinlock, it is really bad to then call schedule, since a
>another process that will grab that same spinlock will deadlock the CPU
>(on an SMP system). Since you are using locks (I'm also assuming that
>you are using spinlocks) I assume that you will be running this on a
>CONFIG_PREEMPT or SMP system.
>
>So the fix will be to release the lock before calling something that
>will schedule, and regrab it afterwards.
>  
>
Sorry for not being too precise. Yes, your assumptions were correct ;-)
I grab a lock using

spin_lock(&ieee->lock);

and release it using

spin_unlock(&ieee->lock);

there is quite a lot of debugging printk's inbetween. Can this be a cause ?

Re: "scheduling while atomic" ?

[Steven Rostedt]

On Tue, 2005-07-12 at 16:08 +0200, Mateusz Berezecki wrote:

> Sorry for not being too precise. Yes, your assumptions were correct ;-)
> I grab a lock using
> 
> spin_lock(&ieee->lock);
> 
> and release it using
> 
> spin_unlock(&ieee->lock);
> 
> there is quite a lot of debugging printk's inbetween. Can this be a cause ?
> 

No.

You previous showed the following output:

scheduling while atomic: insmod/0x00000001/12692
 [<c03e7352>] schedule+0x632/0x640
 [<c0119bb1>] __wake_up_common+0x41/0x70
 [<c03e74df>] wait_for_completion+0x8f/0xf0
 [<c0119b50>] default_wake_function+0x0/0x20
 [<c0119b50>] default_wake_function+0x0/0x20
 [<c012e2dd>] queue_work+0x8d/0xa0
 [<c012e070>] __call_usermodehelper+0x0/0x70
 [<c012e1a5>] call_usermodehelper_keys+0xc5/0xd0
 [<c012e070>] __call_usermodehelper+0x0/0x70
 [<c020c028>] sprintf+0x28/0x30
 [<c020955d>] kobject_hotplug+0x29d/0x310
 [<c019fc6e>] sysfs_create_link+0x3e/0x60
 [<c028b601>] class_device_add+0x161/0x1e0
 [<c036f38e>] netdev_register_sysfs+0x3e/0x100
 [<c03650db>] netdev_run_todo+0x1eb/0x220
 [<c0364dce>] register_netdev+0x5e/0x90

I assume that you call register_netdev in your module. Since this was
running insmod, this is probably called from the module_init. So what
reason do you have a lock from beginning to end?  Looking at this, you
can't call register_netdev while holding a spin_lock since it looks like
it will schedule.  So the fix is to release whatever spin lock that you
have before calling register_netdev.

-- Steve

Re: "scheduling while atomic" ?

[Mateusz Berezecki]

Steven Rostedt wrote:

>I assume that you call register_netdev in your module. Since this was
>running insmod, this is probably called from the module_init. So what
>reason do you have a lock from beginning to end?  Looking at this, you
>can't call register_netdev while holding a spin_lock since it looks like
>it will schedule.  So the fix is to release whatever spin lock that you
>have before calling register_netdev.
>  
>
Thank you for your help. This actually works ;-)

--mb