web-dev-qa-db-fra.com

Comment résoudre "BUG: planification en atomique: swapper / 0x00000103 / 0, CPU # 0"? dans le pilote TSC2007?

J'ai trouvé le pilote tsc2007 et modifié selon nos besoins. Notre entreprise produit sa propre carte TI DM365. Dans cette carte, nous avons utilisé TSC2007 et connecté la broche PENIRQ à GPIO0 de DM365. Il est vu OK sur le pilote. lorsque je touche pour que le curseur de l'écran tactile bouge mais que je reçois en même temps

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

avertissement et Linux intégré est en train de planter. il y a 2 fichiers que j'ai modifiés et téléchargés sur http://www.muhendislikhizmeti.com/touchscreen.Zip l'un est avec une minuterie, l'autre ne l'est pas. il donne en tout cas cette erreur.

J'ai trouvé une solution sur le Web avec laquelle j'ai besoin d'utiliser la file d'attente de travail et d'appeler en utilisant l'API schedule_work (). mais ils sont flous pour moi maintenant. Quelqu'un a-t-il une idée de la façon de résoudre ce problème et peut me donner des conseils par où commencer à utiliser la file d'attente de travail.

clinux-kernel
22
Ali Bingöl

"Planification en atomique" indique que vous avez essayé de dormir quelque part que vous ne devriez pas - comme dans une section critique protégée par un verrou tournant ou un gestionnaire d'interruption.

Les exemples courants de choses qui peuvent dormir sont mutex_lock(), kmalloc(..., GFP_KERNEL), get_user() et put_user().

33
caf

Exactement comme dit dans la 1ère réponse, l'ordonnancement en atomique se produit lorsque l'ordonnanceur est confus et donc incapable de fonctionner correctement et ce parce que l'ordonnanceur a tenté d'effectuer un "schedule ()" dans une section qui contient un code programmable à l'intérieur d'un non programmable .

Par exemple, utiliser des dort à l'intérieur d'une section protégée par un verrou tournant. Essayer d'utiliser un autre verrou (sémaphores, mutex ..) à l'intérieur d'un code protégé par un verrou tournant peut également perturber le planificateur. De plus, l'utilisation de verrous rotatifs dans l'espace utilisateur peut conduire le planificateur à se comporter comme tel. J'espère que cela t'aides

14
ag lotfi

Pour toute autre personne ayant une erreur similaire - j'ai eu ce problème parce que j'avais une fonction, appelée à partir d'un contexte atomique, qui utilisait kzalloc(..., GFP_KERN) alors qu'elle aurait dû utiliser GFP_NOWAIT ou GFP_ATOMIC.

Ceci n'est qu'un exemple d'une fonction qui se met en veille quand vous ne le souhaitez pas, ce à quoi vous devez faire attention dans la programmation du noyau.

J'espère que cela sera utile à quelqu'un d'autre!

5
Luke Wren

Merci pour les deux premières réponses, dans mon cas, il suffisait de désactiver la préemption:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();
2
Zeb