How to solve “BUG: scheduling while atomic: swapper /0x00000103/0, CPU#0”? in TSC2007 Driver?

Question

I found tsc2007 driver and modified according to our needs. Our firm is producing its own TI DM365 board. In this board we used TSC2007 and connected PENIRQ pin to GPIO0 of

Answer 1

Thanks for the former two answers, in my case it was enough to disable the preemption:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();

Answer 2

"Scheduling while atomic" indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler.

Common examples of things that can sleep are mutex_lock(), kmalloc(..., GFP_KERNEL), get_user() and put_user().

Answer 3

For anyone else with a similar error - I had this problem because I had a function, called from an atomic context, that used kzalloc(..., GFP_KERN) when it should have used GFP_NOWAIT or GFP_ATOMIC.

This is just one example of a function sleeping when you don't want to, which is something you have to be careful of in kernel programming.

Hope this is useful to somebody else!

Answer 4

Exactly as said in 1st answer, scheduling while atomic happens when the scheduler gets confused and therefore unable to work properly and this because the scheduler tried to perform a "schedule()" in a section that contains a schedulable code inside of a non schedulable one.

For example using sleeps inside of a section protected by a spinlock. Trying to use another lock(semaphores,mutexes..) inside of a spinlock-proteced code may also disturb the scheduler. In addition using spinlocks in user space can drive the scheduler to behave as such. Hope this helps