Wie zu lösen "BUG: Scheduling während atomic: swapper/0x00000103/0, CPU # 0"? im TSC2007 Treiber?

Question

Ich fand TSC2007 Treiber und modifiziert nach unseren Bedürfnissen. Unsere Firma produziert ein eigenes TI DM365 Board. In dieser Platine haben wir TSC2007 verwendet und den PENIRQ-Pin mit GPIO0 von DM365 verbunden. Es ist OK auf Fahrer gesehen. wenn ich den touchscreen berühre, bewegt sich der cursor, aber gleichzeitig bekomme ich

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

warning und embedded Linux wird abgestürzt. Es gibt 2 Dateien, die ich geändert und auf http://www.muhendislikhizmeti.com/touchscreen.zip hochgeladen habe. Einer ist mit Timer, der andere nicht. Es gibt auf jeden Fall diesen Fehler.

Ich habe eine Lösung im Web gefunden, die ich Arbeitswarteschlange verwenden und mit Schedule_work() API aufrufen muss. aber sie sind jetzt Unschärfe für mich. Hat jemand eine Idee, wie man dieses Problem löst und kann mir einen Rat geben, wo ich anfangen soll, Arbeitswarteschlange zu verwenden.

Answer 1

"Scheduling while atomic" zeigt an, dass Sie versucht haben, irgendwo zu schlafen, was Sie nicht tun sollten - wie in einem Spinlock-geschützten kritischen Abschnitt oder einem Interrupt-Handler.

Gängige Beispiele für Dinge, die sind mutex_lock() schlafen können, kmalloc(..., GFP_KERNEL), get_user() und put_user().

Answer 2

Genau wie in der ersten Antwort gesagt, Scheduling während atomaren geschieht, wenn der Scheduler verwirrt und daher nicht richtig arbeiten kann, und dies, weil der Scheduler versucht, eine "schedule()" in einem Abschnitt, der einen schedulable Code innerhalb enthält ein nicht planbarer.

Zum Beispiel mit Schlaf innerhalb eines durch einen Spinlock geschützten Abschnitts. Der Versuch, eine andere Sperre (Semaphore, Mutexe ...) innerhalb eines Spinlock-geschützten Codes zu verwenden, kann den Scheduler ebenfalls stören. Darüber hinaus kann die Verwendung von Spinlocks im Benutzerbereich dazu führen, dass sich der Scheduler so verhält. Hope this

Answer 3

Danke für die ersten beiden Antworten hilft, in meinem Fall war es genug, um das Vorkaufsrecht zu deaktivieren:

preempt_disable(); 

// Your code with locks and schedule() 

preempt_enable(); 

Answer 4

Für alle andere mit einem ähnlichen Fehler - ich hatte dieses Problem, weil ich eine Funktion hatte, aus einem atomaren Kontext aufgerufen, der kzalloc(..., GFP_KERN) verwendet, wenn es GFP_NOWAIT oder GFP_ATOMIC hätte verwenden sollen.

Dies ist nur ein Beispiel für eine Funktion, die schläft, wenn Sie nicht wollen, was bei der Kernel-Programmierung zu beachten ist.

Hoffe das ist nützlich für jemand anderen!