Wie löse ich „BUG: Scheduling While Atomic: Swapper /0x00000103/0, CPU#0“? im TSC2007-Treiber?

Ich habe den tsc2007-Treiber gefunden und entsprechend unseren Bedürfnissen modifiziert. Unsere Firma produziert ihr eigenes TI DM365-Board. In diesem Board haben wir TSC2007 verwendet und den PENIRQ-Pin mit GPIO0 von DM365 verbunden. Es wird vom Fahrer in Ordnung gesehen. Wenn ich den Touchscreen berühre, bewegt sich der Cursor, aber gleichzeitig bekomme ich

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

Warnung und eingebettetes Linux wird abgestürzt. Es gibt 2 Dateien, die ich geändert und hochgeladen habe http://www.muhendislikhizmeti.com/touchscreen.zip Der eine ist mit Timer, der andere nicht. es gibt diesen Fehler in jedem Fall.

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

“Scheduling while atomic” zeigt an, dass Sie versucht haben, irgendwo zu schlafen, wo Sie es nicht tun sollten – wie in einem durch Spinlocks geschützten kritischen Abschnitt oder einem Interrupt-Handler.

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

Genau wie in der ersten Antwort gesagt, geschieht die Planung im atomaren Zustand, wenn der Planer verwirrt wird und daher nicht richtig funktionieren kann, und dies, weil der Planer versucht hat, einen “Schedule()” in einem Abschnitt auszuführen, der einen planbaren Code innerhalb eines nicht planbaren Codes enthält .

Zum Beispiel die Verwendung von Sleeps innerhalb eines Abschnitts, der durch ein Spinlock geschützt ist. 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 Benutzerraum den Planer dazu bringen, sich so zu verhalten. Hoffe das hilft

Für alle anderen mit einem ähnlichen Fehler – ich hatte dieses Problem, weil ich eine Funktion hatte, die aus einem atomaren Kontext aufgerufen wurde kzalloc(..., GFP_KERN) wann es hätte verwendet werden sollen GFP_NOWAIT oder GFP_ATOMIC.

Dies ist nur ein Beispiel für eine Funktion, die schläft, wenn Sie es nicht wollen, worauf Sie bei der Kernel-Programmierung achten müssen.

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

Danke für die ersten beiden Antworten, in meinem Fall hat es gereicht, die Präemption zu deaktivieren:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();