Как решить "BUG: планирование пока атомное: swapper /0x00000103/0, CPU#0"? в TSC2007 Драйвер?

Question

Я нашел драйвер tsc2007 и изменил в соответствии с нашими потребностями. Наша фирма производит собственную плату TI DM365. В этой плате мы использовали TSC2007 и подключили вывод PENIRQ к GPIO0 DM365. Это замечено на водителе. когда я касаюсь сенсорного экрана курсор движется, но в то же время я получаю

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

предупреждение и встроенный Linux падает. Есть 2 файла, которые я изменил и загрузил на http://www.muhendislikhizmeti.com/touchscreen.zip один с таймером, другой нет. это дает эту ошибку в любом случае.

Я нашел решение в Интернете, что мне нужно использовать рабочую очередь и звонить с использованием schedule_work() API. но они размыты для меня сейчас. Кто-нибудь есть какие-либо идеи, как решить эту проблему и может дать мне несколько советов, с чего начать использовать рабочую очередь.

Answer 1

"Планирование в атомарном режиме" означает, что вы пытались заснуть где-то, что не следует делать - например, в критической секции, защищенной спин-блокировкой, или обработчике прерываний.

Типичные примеры вещей, которые могут спать: mutex_lock(), kmalloc(..., GFP_KERNEL), get_user() а также put_user(),

Answer 2

Точно так же, как сказано в 1-м ответе, планирование в то время как атомарное происходит, когда планировщик запутался и, следовательно, не может работать должным образом, и это потому, что планировщик попытался выполнить "schedule()" в разделе, который содержит планируемое код внутри не планируемое,

Например, использование спящих внутри секции, защищенной спин-блокировкой. Попытка использовать другую блокировку (семафоры, мьютексы...) внутри кода, защищенного спин-блокировкой, также может нарушить работу планировщика. Кроме того, использование спин-блокировки в пользовательском пространстве может заставить планировщик вести себя как таковой. Надеюсь это поможет

Answer 3

Для любого другого с подобной ошибкой - у меня была эта проблема, потому что у меня была функция, вызванная из атомарного контекста, который использовал kzalloc(..., GFP_KERN) когда он должен был использовать GFP_NOWAIT или же GFP_ATOMIC,

Это всего лишь один пример функции, спящей, когда вы не хотите, и с которой вам следует быть осторожным в программировании ядра.

Надеюсь, что это полезно для кого-то еще!

Answer 4

Спасибо за первые два ответа, в моем случае этого было достаточно, чтобы отключить выгрузку:

preempt_disable();

// Your code with locks and schedule()

preempt_enable();