c - torvalds - ultima version de linux

¿Cómo resolver “BUG: programar mientras que atomic: swapper/0x00000103/0, CPU#0”? en el controlador TSC2007?

Question

Encontré el controlador tsc2007 y lo modifiqué según nuestras necesidades. Nuestra firma está produciendo su propia placa TI DM365. En esta placa utilizamos TSC2007 y el pin PENIRQ conectado a GPIO0 de DM365. Se está viendo bien en el controlador. cuando toco el cursor de la pantalla táctil se está moviendo pero al mismo tiempo estoy recibiendo

BUG: scheduling while atomic: swapper /0x00000103/0, CPU#0

advertencia y Linux incrustado se está estrellando. Hay 2 archivos que modifiqué y subí a http://www.muhendislikhizmeti.com/touchscreen.zip Uno está con temporizador, el otro no. Se está dando este error en cualquier caso.

Encontré una solución en la web que necesito para usar la cola de trabajo y llamar con la API schedule_work (). pero ahora son borrosas para mi. ¿Alguien tiene alguna idea de cómo resolver este problema y puede darme algunos consejos sobre dónde empezar a usar la cola de trabajo?

Answer 1

"Programación mientras atómica" indica que has intentado dormir en algún lugar que no deberías, como en una sección crítica protegida con un spinlock o un controlador de interrupciones.

Ejemplos comunes de cosas que pueden dormir son mutex_lock() , kmalloc(..., GFP_KERNEL) , get_user() y put_user() .

Answer 2

Exactamente como se dijo en la 1ra respuesta, la programación mientras atómica ocurre cuando el programador se confunde y, por lo tanto, no puede funcionar correctamente y esto se debe a que el programador intentó realizar un "schedule ()" en una sección que contiene un código programable dentro de uno no programable .

Por ejemplo, usar sleeps dentro de una sección protegida por un spinlock. Tratar de usar otro bloqueo (semáforos, mutexes ...) dentro de un código protegido por spinlock también puede perturbar al programador. Además, el uso de spinlocks en el espacio de usuario puede hacer que el programador se comporte como tal. Espero que esto ayude

Answer 3

Gracias por las dos primeras respuestas, en mi caso fue suficiente para deshabilitar la prioridad:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();

Answer 4

Para cualquier otra persona con un error similar: tuve este problema porque tenía una función, llamada desde un contexto atómico, que usaba kzalloc(..., GFP_KERN) cuando debería haber usado GFP_NOWAIT o GFP_ATOMIC .

Este es solo un ejemplo de una función que está inactiva cuando no quiere, que es algo que debe tener cuidado en la programación del kernel.

Espero que esto sea útil para alguien más!